java-gnome-hackers Mailing List for The java-gnome language bindings project (Page 15)
Brought to you by:
afcowie
Menu
βΎ
β΄
java-gnome-hackers — Hacking on the bindings themselves: design issues and co-ordination
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(102) |
Sep
(43) |
Oct
(32) |
Nov
(43) |
Dec
(51) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(19) |
Mar
(39) |
Apr
(22) |
May
|
Jun
(11) |
Jul
(2) |
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(9) |
Dec
(73) |
| 2004 |
Jan
(88) |
Feb
(141) |
Mar
(116) |
Apr
(69) |
May
(199) |
Jun
(53) |
Jul
(90) |
Aug
(23) |
Sep
(11) |
Oct
(212) |
Nov
(57) |
Dec
(61) |
| 2005 |
Jan
(88) |
Feb
(17) |
Mar
(21) |
Apr
(50) |
May
(44) |
Jun
(33) |
Jul
(21) |
Aug
(37) |
Sep
(39) |
Oct
(43) |
Nov
(40) |
Dec
(15) |
| 2006 |
Jan
(21) |
Feb
(69) |
Mar
(23) |
Apr
(6) |
May
(29) |
Jun
(19) |
Jul
(17) |
Aug
(15) |
Sep
(13) |
Oct
(16) |
Nov
(9) |
Dec
(7) |
| 2007 |
Jan
(30) |
Feb
(39) |
Mar
(1) |
Apr
(12) |
May
(53) |
Jun
(30) |
Jul
(39) |
Aug
(75) |
Sep
(16) |
Oct
(13) |
Nov
(20) |
Dec
(5) |
| 2008 |
Jan
(8) |
Feb
(14) |
Mar
(33) |
Apr
(7) |
May
(22) |
Jun
(23) |
Jul
(17) |
Aug
(9) |
Sep
(9) |
Oct
(25) |
Nov
(9) |
Dec
(1) |
| 2009 |
Jan
(20) |
Feb
(38) |
Mar
(9) |
Apr
(15) |
May
(30) |
Jun
(35) |
Jul
(22) |
Aug
(10) |
Sep
(7) |
Oct
(23) |
Nov
(6) |
Dec
(8) |
| 2010 |
Jan
(5) |
Feb
(10) |
Mar
(17) |
Apr
(10) |
May
(16) |
Jun
(8) |
Jul
(3) |
Aug
(15) |
Sep
(14) |
Oct
(26) |
Nov
(11) |
Dec
(14) |
| 2011 |
Jan
(10) |
Feb
(8) |
Mar
(6) |
Apr
(7) |
May
(18) |
Jun
(17) |
Jul
(6) |
Aug
(1) |
Sep
(2) |
Oct
(6) |
Nov
(2) |
Dec
(10) |
| 2012 |
Jan
(6) |
Feb
(9) |
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
(5) |
Aug
(14) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(8) |
Mar
(6) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andrew C. <an...@op...> - 2009-08-14 04:55:47
|
I just made an ABI break.
It's a teeny tiny one, and as a signature fix it comes under the warning
on the main /4.0/ web page.
The fix is going in (it has to), but I am debating whether this should
cue a bump in java-gnome's API version number.
ie, we are [quite deliberately] set up as
epoch.api.version
right now. So the next release will either be
4.0.13
or
4.1.1
The glitch in question is that we had gunichar registered as Java char,
not Java int. So, surprise, splat. The method that is changing is
TextIter's getChar(), now returning int.
No one with a widely distributed libre codebase is using it, so I don't
feel compelled to bump java-gnome's API version number, but I thought
I'd let you know I was thinking about it.
[if it wasn't for the fact that StringBuffer's append(int) doesn't
append the codepoint but instead does a Integer.toString(int), this
would have been transparent. Alas]
If I do, I'll remove all the @deprecated stuff at the same time.
AfC
Sydney
--
Andrew Frederick Cowie
Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.
http://www.operationaldynamics.com/
Sydney New York Toronto London
|
|
From: Serkan K. <se...@ge...> - 2009-08-01 07:59:32
|
Just to point out I found the original documents I intented to mention. http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/types.html section on "Modified UTF-8" (Actually I spotted this somewhere in api docs but anyway it explains the exact same stuff) http://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8 and also javadoc of java.lang.Character Sincerely Serkan KABA |
|
From: Andrew C. <an...@op...> - 2009-07-31 14:12:49
|
On Fri, 2009-07-31 at 11:34 +0300, Serkan Kaba wrote: > Although I don't work with that math symbols nor weird characters, > thanks for discovering and fixing the issue. I tested libnotify and my > last.fm tutorial against it and they work just fine. Thanks Serkan. That makes three people who have checked in and said things were ok. I think we'll go with this; merged to 'mainline'. If anyone who encounters a problem, *please* send a TestCase subclass [sure, go ahead and just add a fixture to ValidateUnicode] that fails so we can debug with your use case. Thanks! AfC Sydney -- Andrew Frederick Cowie Operational Dynamics is an operations and engineering consultancy focusing on IT strategy, organizational architecture, systems review, and effective procedures for change management: enabling successful deployment of mission critical information technology in enterprises, worldwide. http://www.operationaldynamics.com/ Sydney New York Toronto London |
|
From: Serkan K. <se...@ge...> - 2009-07-31 08:34:25
|
Although I don't work with that math symbols nor weird characters, thanks for discovering and fixing the issue. I tested libnotify and my last.fm tutorial against it and they work just fine. Sincerely, Serkan KABA |
|
From: Serkan K. <se...@ge...> - 2009-07-28 10:18:02
|
2009/7/28 Andrew Cowie <an...@op...>: > Does the SexySpellEntry Entry subclass use the same back-end that the > TextView augmented with GtkSpell does? > > ie, > > - same UI [popup of word suggestions, etc]? The UI I dont remember but the word segmentation code definetely differs (GtkSpell uses TextView's own mechanism where as libsexy implements a *buggy* logic of its own. > > - same back-end [presumably enchant powered to $whichever engine]? Yes they're both Enchant powered and most of the logic for enchant calls are duplicated. The difference is SexySpellEntry is not linked against enchant but uses dlopen > There is nothing worse than having keep adding all my words to > yet-another spell checking back-end; it would be a non-starter if you > had a java-gnome application full of TextViews and Entries that used a > *different* spell checking dictionary for each. The suggestions will be the same assuming there are no non-ascii chars in the text triggering the libsexy bug. Serkan KABA |
|
From: Andrew C. <an...@op...> - 2009-07-28 09:57:02
|
On Tue, 2009-07-28 at 06:56 +0300, Serkan Kaba wrote: > 2009/7/28 Andrew Cowie <an...@op...>: > > Does SexySpellEntry use the same back end that GtkSpell does? > The difference is GtkSpell is attached to TextView's (multiline) but > SexySpellEntry is a subclass of GtkEntry (single line) Yup, I know what the difference between an Entry and a TextView is. :) Let me try asking a different way: Does the SexySpellEntry Entry subclass use the same back-end that the TextView augmented with GtkSpell does? ie, - same UI [popup of word suggestions, etc]? - same back-end [presumably enchant powered to $whichever engine]? There is nothing worse than having keep adding all my words to yet-another spell checking back-end; it would be a non-starter if you had a java-gnome application full of TextViews and Entries that used a *different* spell checking dictionary for each. AfC Sydney |
|
From: Andrew C. <an...@op...> - 2009-07-28 07:42:32
|
Tests this week have uncovered serious problems when you try to put a supplementary character (a Unicode character whose index is > 0xFFFF and which therefore needs > 1 2-byte char to represent). The case I've been working with is U+1D45B, the π character from the Mathematical Alphanumeric Symbols block http://www.fileformat.info/info/unicode/char/1d45b/index.htm It doesn't matter to us what Java does internally because when we leave Java and pass string data to GNOME we have [of course] used the JNI function GetStringUTFChars() which takes a jstring [ie, java.lang.String] and returns a char* [ie, const gchar*] to a UTF-8 representation of the string. I'd tested this heavily in the past; ValidatePangoTextRendering and others. All good, especially with characters > 0x7f and > 0xFF, ie, two or three bytes in UTF-8. But when I tried entering π and π [which have to be 2 Java chars wide (UTF-16) and more to the point are *four* UTF-8 bytes wide] into a TextView, the resultant call through gtk_text_buffer_insert() resulted in an g_utf8_validate() assertion failure. Oh shit. Not valid UTF-8! What the heck? The obvious conclusion is that GetStringUTFChars() doesn't return valid UTF-8 after all. Serkan tells me that this is a fairly well known problem; he pointed me to http://www.ingrid.org/java/i18n/utf-16/ (frankly that page makes it even _more_ confusing) but digging around the JNI spec it vaguely talks about the UTF-8 support being limited to 3-bytes. So, oh shit, confirmed. Yes, I could live without the π character, but the work I'm doing is aimed at (among other things) mathematical and physics manuscripts, and so I know I'm going to have people hitting this problem. More to the point, it just doesn't do for a valid character that the rest of GNOME handles fine to not work when paste or typed into a java-gnome Widget. And I get the impression that there's a lot of CJK and Indic activity up in supplementary range, so this needs addressing. What to do about this? I poked around a bit, and it didn't take long to find that GLib has a set of conversion functions. g_utf16_to_utf8() seems promising, right? Anyone who read 1b-Homework knows that JNI has two sets of string functions: GetStringChars() and GetStringUTFChars(); NewString() and NewStringUTF(). I'd long wondered about the existence of the first set; their documentation talks about "getting real unicode characters" instead of UTF-8 encoded ones. [Ah, such hubris. Remember when everyone laughed at Java because we all thought 2 byte char was hardly necessary? Amazing that 10 years later 2 bytes is not enough; makes the UTF-8 choice back around the time of GLib and XML look like a pretty good call] So that got me wondering just what Java's (well, JNI's) idea of a "unicode character" (sic) actually is. It took a bit of digging, but it seems they actually mean UTF-16 encoding. See http://java.sun.com/javase/technologies/core/basic/intl/faq.jsp#core-textrep which seems to say fairly authoritatively (nothing like a FAQ, heh) that Java uses UTF-16 in the char[] that back String objects. Ok. If GetStringChars()'s "unicode characters" (sic) are valid UTF-16 characters, then we can use g_utf16_to_utf8() to get *real* UTF-8 to feed to GTK's and other GNOME libraries' functions. And g_utf8_to_utf16() + NewString() to go the other way. ++ I prototyped it and it stopped my apps from thundering in. Good sign. So I implemented it for real. Doing the code generator was a snap (yeay); it only took a few hours to get all the hand written code as well. See branch 'hackers/andrew/unicode' at bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/unicode/ New functions: bindings_java_getString(); bindings_java_newString(); There's a: bindings_java_releaseString() which mirrors JNI's ReleaseStringUTFChars() and should be called on strings returned by the bindings_java_getString() above. I was actually able to use JNI's GetStringCritical() and ReleaseStringCritical() functions. These are "dangerous" but gives us a jchar* pointer to the actual char[] in the VM's managed heap space, which saves us a copy. I think they're being used correctly. Did I use const correctly? ++ As far as I can tell this all works and is safe. Performance of bindings_java_getString() seems comparable to the JNI GetStringUTFChars(), so that's good. Please PLEASE test this branch with your apps. It is a hugely invasive change to java-gnome's internal working, so it's not just a case of "oh, I don't use high-range characters". This impacts *all* string handling, so I'd appreciate some testing before we decide to accept this approach. If you've got a better idea for an implementation, we now have all Java -> C string conversion abstracted into one place, so you can experiment there if you want to. AfC Sydney -- Andrew Frederick Cowie Operational Dynamics is an operations and engineering consultancy focusing on IT strategy, organizational architecture, systems review, and effective procedures for change management: enabling successful deployment of mission critical information technology in enterprises, worldwide. http://www.operationaldynamics.com/ Sydney New York Toronto London |
|
From: Serkan K. <se...@ge...> - 2009-07-28 03:56:45
|
2009/7/28 Andrew Cowie <an...@op...>: > Does SexySpellEntry use the same back end that GtkSpell does? The difference is GtkSpell is attached to TextView's (multiline) but SexySpellEntry is a subclass of GtkEntry (single line) It has a bug in handling non-ascii chars [1] but it looks better when it comes to single line editing. But I prefered gtkspell over libsexy for xchat in Gentoo) By the way the main reason I started the brach is SexySpellEntry 1:' http://bugzilla.gnome.org/show_bug.cgi?id=559982 Regards, Serkan Kaba |
|
From: Andrew C. <an...@op...> - 2009-07-28 03:28:16
|
On Mon, 2009-07-27 at 21:37 +0200, Guillaume Mazoyer wrote: > I'm interesting in continuing your libsexy work. I guess we should > take care while implementing SexyIconEntry stuffs. Since GTK+ 2.16 On the one hand, libsexy is cool. On the other hand, some people are trying to get rid of it: http://live.gnome.org/GnomeGoals/DropLibsexy I'm not sure how Christian feels about that, or how we should feel about that. As far as I can tell, all the icon Γ Entry functionality is in GTK 2.17 (if not 2.16). Does SexySpellEntry use the same back end that GtkSpell does? I know the new tooltip API is powerful, but I don't know if it does what sexy offers. > we must push GTK requirement to version 2.16 There are several branches floating around that require gtk+ >= 2.16, and we agreed previously that we would bump the dep to 2.16 during this cycle. So go ahead. Anyway, I'm not against a libsexy dependency, but if GNOME is trying to remove it, maybe we should think twice about it. AfC Sydney |
|
From: Guillaume M. <res...@gm...> - 2009-07-27 19:37:29
|
Hi Serkan, I'm interesting in continuing your libsexy work. I guess we should take care while implementing SexyIconEntry stuffs. Since GTK+ 2.16, we can now use icon for entries and use those entries like a progress bar too. I implemented this cool stuffs in my own branch. http://research.operationaldynamics.com/bzr/java-gnome/hackers/guillaume/entry-gtk-2.16/ As I said, we must push GTK requirement to version 2.16 before merging it. I still want to work on libsexy so I'll try to do what I can to get your work completed and merged. -- Guillaume Mazoyer (Respawner) - http://www.respawner.fr/ |
|
From: Serkan K. <se...@ge...> - 2009-07-27 16:19:28
|
Iβll be unavailable for a period of time, so my Java-Gnome development will halt during that period. As a result Iβm looking for contributors to continue my incomplete branches. Vte: http://research.operationaldynamics.com/bzr/java-gnome/hackers/serkan/vte/ VTE library provides a terminal widget which powers Gnome Terminal and other GTK+ terminal emulators. The purpose of this branch to add coverage of VTE API. Sexy: http://research.operationaldynamics.com/bzr/java-gnome/hackers/serkan/sexy/ Libsexy provides additional widgets for GTK+. The purpose of this branch to add coverage of widgets provided by Libsexy. Gerrorcode: http://research.operationaldynamics.com/bzr/java-gnome/hackers/serkan/gerrorcode/ Current implementation of GlibException doesnβt capture error code and error domain associated with a GError. The purpose of this branch is to add necessary native and Java bits to provide those these two properties. Linkbutton: http://research.operationaldynamics.com/bzr/java-gnome/hackers/serkan/linkbutton/ LinkButton is a widget providing an HTML anchor like link. The purpose of this branch is to cover LinkButton. And thanks in advance to people who take over the development of the branches. And special thanks to Andrew Cowie who helped throughout my Java-Gnome development. Sincerely, Serkan KABA |
|
From: Roberto <evo...@ya...> - 2009-07-24 14:53:28
|
Hi,
I discussed the problem on IRC. Finally I found that removing some
configuration from %HOME/.bashrc configure worked better, and with jdk
defined, perfectly.
The lines I commented in $HOME/.bashrc:
---------------------------------------------------------------------
## JAVA ##
JAVA_HOME="$HOME/Programas/jdk1.6.0_14"
PATH="$JAVA_HOME/bin:$PATH"
export JAVA_HOME
export PATH
## ANT ##
PATH="/home/rlin/Programas/apache-ant-1.7.1/bin:$PATH"
export PATH
---------------------------------------------------------------------
I hope this helps someone
bye
2009/7/23 Roberto <evo...@ya...>
> Hi, I'm new to the list and to java-gnome.
>
> I was telling on the #java-gnome IRC channel about a problem with
> ./configure in Ubuntu 9.04 32bits with 4.0.11 release and bzd mainline. The
> output is:
>
> java-gnome-4.0.11$ ./configure
>
> equivalence, v0.2
> ...configuring Java projects to build and run on Linux & Unix
>
> Identify operating system: Debian
>
> Check for required jar files:
> - JUnit test framework found
>
> Check for required system libraries:
> - GTK+ found
> - Pango found
> - ATK found
> - GDK found
> - LibGlade found
>
> - GNOME printing (Unix backend) found
>
> Check Java compilers:
> - Eclipse ecj works
> - System javac works
> - GNU gcj -C (bytecode mode) works
> - GNU gcjh found
>
> - GNU fastjar works
> - GNU gjdoc found
>
> Check Java virtual machines:
> - System java VM doesn't work
> - GNU gij doesn't work
>
> Check native compiler:
> - GNU gcc works
>
> Can't use GCJ, insufficiently recent version
>
> Select compiler: ecj
> Select runtime: java
> failed
>
> Can't locate the JNI header file
>
> Failed to complete configuration.
>
>
> I could fix it adding some lines to the sections that deals with GCC configuration:
>
> + } elsif (-f "/usr/lib/gcc/i486-linux-gnu/4.3/include/jni.h") {
>
> + $jni_include = "-I/usr/lib/gcc/i486-linux-gnu/4.3/include/jni.h";
>
> With java-gnome 4.0.12-rc3 I have no problem.
>
>
>
|
|
From: Andrew C. <an...@op...> - 2009-07-24 08:04:34
|
See IRC channel :) AfC Sydney |
|
From: Andrew C. <an...@op...> - 2009-07-24 01:44:07
|
On Thu, 2009-07-23 at 20:02 +0200, Roberto wrote: > > I was telling on the #java-gnome IRC channel about a problem > with ./configure in Ubuntu 9.04 32bits with 4.0.11 release and bzr > mainline. ... > With java-gnome 4.0.12-rc3 I have no problem. That makes no sense at all. 4.0.13-rc3 *is* current 'mainline' tip. Further, nothing related to this has changed in the top level configure since 4.0.11 was cut. There must have been something else about the way Roberto was running configure that is different, but he said that everything else was held constant. So really I don't know what to suggest. If there is a real problem, then we do want to find it and fix it, but based on "with java-gnome 4.0.12-rc3 I have no problem," I think that I'll go ahead and not block the release on this. Please keep an eye out for whatever this is, though. Something sounds screwy. AfC Sydney |
|
From: Roberto <evo...@ya...> - 2009-07-23 18:03:00
|
Hi, I'm new to the list and to java-gnome.
I was telling on the #java-gnome IRC channel about a problem with
./configure in Ubuntu 9.04 32bits with 4.0.11 release and bzd mainline. The
output is:
java-gnome-4.0.11$ ./configure
equivalence, v0.2
...configuring Java projects to build and run on Linux & Unix
Identify operating system: Debian
Check for required jar files:
- JUnit test framework found
Check for required system libraries:
- GTK+ found
- Pango found
- ATK found
- GDK found
- LibGlade found
- GNOME printing (Unix backend) found
Check Java compilers:
- Eclipse ecj works
- System javac works
- GNU gcj -C (bytecode mode) works
- GNU gcjh found
- GNU fastjar works
- GNU gjdoc found
Check Java virtual machines:
- System java VM doesn't work
- GNU gij doesn't work
Check native compiler:
- GNU gcc works
Can't use GCJ, insufficiently recent version
Select compiler: ecj
Select runtime: java
failed
Can't locate the JNI header file
Failed to complete configuration.
I could fix it adding some lines to the sections that deals with GCC
configuration:
+ } elsif (-f "/usr/lib/gcc/i486-linux-gnu/4.3/include/jni.h") {
+ $jni_include = "-I/usr/lib/gcc/i486-linux-gnu/4.3/include/jni.h";
With java-gnome 4.0.12-rc3 I have no problem.
|
|
From: Andrew C. <an...@op...> - 2009-07-21 14:08:17
|
On Mon, 2009-07-20 at 15:03 +0200, Guillaume Mazoyer wrote: > I pushed it into my entry-completion branch Merged to 'mainline'. It was a probably mistake to hold the release up for this, but Guillaume worked hard on his branch and I wanted to see his work accepted if we could get it finished. So well done! This branch was fairly big so I've uploaded a third and final 4.0.12 release candidate. If anyone has any problems, please speak up. AfC Sydney |
|
From: Guillaume M. <res...@gm...> - 2009-07-20 13:03:47
|
Hello, I finally know more about insert_prefix() and complete() method of gtk_entry_completion. These methods do *not* allow us to complete the GtkEntry object as we expected. Actuallly, complete() just refresh the completion list, inert_prefix() will just insert the prefix (for Albert and Alice, the prefix will be "Al") and to force the entry to be completed we must send the match_selected signal by hand. So now, the emitMatchSelected(TreeIter) method will do that in the EntryCompletion class. By the way, it fixes the test case. I pushed it into my entry-completion branch which should be ready to be merged now. -- Guillaume Mazoyer (Respawner) - http://www.respawner.fr/ |
|
From: Guillaume M. <res...@gm...> - 2009-07-15 13:03:35
|
Hey Andrew, I think I understand how does that "completion" using "complete()" and "insertPrefix()" method works. Actually, I thought that it was the "complete()" method that will complete the entry. But the fact is that, "complete()" just "refresh" the completion list and "insertPrefix()" *do* the completion. I think it's a little bit weird but this is the way it works (tried with pygtk too). I merged your branch into mine. The only known problem now is the "setMatchCallback()". Completion list is shown correctly but when you choose one of the completion strings the program crashes. Moreover, the custom MatchSignal doesn't not seem to be emitted but "static gboolean emit_match()" is used few times. I'm now lost because of that. -- Guillaume Mazoyer (Respawner) - http://www.respawner.fr/ |
|
From: Andrew C. <an...@op...> - 2009-07-15 06:56:45
|
Hey Guillaume, On Thu, 2009-06-25 at 18:21 +0200, Guillaume Mazoyer wrote: > The unit-test class is in progress but I do not know how to use the > complete() method. I try it also with pygtk and it doesn't seem to > work. Did somebody use this method with another GTK library/binding? I hacked on your test case a bit, and managed to make it pass by chaning a number of the properties from their defaults and then using EntryCompletion's insertPrefix(). The interactions aren't clear. Nor is that method. So I don't know _why_ it worked. That's pretty sad, but I thought I'd be honest :) Can you take what I did and see if you can figure it out? My work building on yours is (again) on branch 'hackers/andrew/entry-completion' AfC Sydney |
|
From: Andrew C. <an...@op...> - 2009-07-15 06:44:17
|
On Mon, 2009-07-13 at 23:10 +1000, jan wrote:
> Clutter requires calling gtk_clutter_init() instead of gtk_init() so
_instead_?
How inconvenient of them.
> I've added Gtk.initClutter()
I imagine that we'll prefer:
Clutter.init(args);
and then some guard logic elsewhere.
That said, there is an enormous amount of additional (very important)
stuff that is done during our call to what we call GtkMain.gtk_init(),
so this won't be trivial.
I'll chat with you about this next time we catch up on IRC.
> I made the Color constructor take ints instead of bytes because
> Color(0, 0, 0) is nicer than Color((byte)0, (byte)0, (byte)0). Is this
> bad style?
Um, Color already has
public <init>(int, int, int);
so I'm not sure what you're talking about there.
> Some of the classes are derived from GInitiallyUnowned but in the
> bindings I made them derive from Object. Will this cause problems?
No, that'll behave. We have a lot of code that deals with those
permutations, but if it decides to act up we'll set Vreixo on it. :)
AfC
Sydney
|
|
From: jan <jan...@gm...> - 2009-07-13 13:26:18
|
Hello all, I've started creating some Clutter bindings which are now available at: bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/jan/clutter To begin with I'm just adding the bits I need so coverage is spotty for now. I'm targeting the current unstable 0.9 release which should be compatible with the upcoming 1.0 release. To use the bindings will require both clutter and clutter-gtk installed, there are no tests for this in the configure file yet. Some issues I'd like some feedback on. Clutter requires calling gtk_clutter_init() instead of gtk_init() so I've added Gtk.initClutter() and a kludge to GtkMain to support this. The problem with this is that accidentally calling Gtk.init() when using the ClutterEmbed widget will crash the VM. Not sure what the best way to deal with this is. I made the Color constructor take ints instead of bytes because Color(0, 0, 0) is nicer than Color((byte)0, (byte)0, (byte)0). Is this bad style? Some of the classes are derived from GInitiallyUnowned but in the bindings I made them derive from Object. Will this cause problems? It seems to work but I haven't looked into how the gc interacts with the ref counting yet. -- jan |
|
From: Andrew C. <an...@op...> - 2009-07-06 01:21:18
|
On Sun, 2009-07-05 at 22:17 +0200, res...@gm... wrote: > Merging this branch to 'mainline' will push us to requiring >= gtk > +-2.16 That's ok. Another branch we have waiting in the wings requires that as well. We'll bump to requiring GTK >= 2.16 after we release java-gnome 4.0.12 They key was waiting until some distros had it out in the wild, but that's starting to be the case now. AfC Sydney |
|
From: <res...@gm...> - 2009-07-05 20:17:34
|
Hello everyone, I started to implement some cool new functions (which was provided by libsexy before) from GtkEntry which was introduced with GTK+ 2.16. I pushed my branch here : http://research.operationaldynamics.com/bzr/java-gnome/hackers/guillaume/entry-gtk-2.16/ Everything seems to work but it still need to be reviewed by some more experienced developers. I will also work on an example and a snapshot. Merging this branch to 'mainline' will push us to requiring >= gtk+-2.16 -- Guillaume Mazoyer (Respawner) - http://www.respawner.fr/ |
|
From: <res...@gm...> - 2009-07-05 07:22:16
|
Hi everyone, (Here is the good list, completion function will kill me someday) I pushed my EntryCompletion work in a branch. http://research.operationaldynamics.com/bzr/java-gnome/hackers/guillaume/entry-completion/ Currently, the example needs to be reworked and the unit-test and snapshot classes needs to be fixed. I'llstill have a NULL value somewhere that I could not find. It will becool if someone can take a (quick) look to the current code to see ifhe sees something strange he can fix. Thank you. -- Guillaume Mazoyer (Respawner) - http://www.respawner.fr/ |
|
From: Andrew C. <an...@op...> - 2009-06-30 01:14:41
|
Hey Serkan. I was hoping to catch you last night. On Mon, 2009-06-29 at 22:07 +0300, Serkan Kaba wrote: > Can you examine this branch quickly, I worked on it yesterday. It's great, except for a few concerns I have about the URI handler part. If you could grab [pull a copy / merge into yours / whatever] 'hackers/andrew/linkbutton', http://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/linkbutton/ you'll see that I added another small unit test in addition to my usual editorial. Along the way, I hit some puzzling behaviour. 1) According to devhelp, in C there is only be one URI hook. Of course, since we happen to use a signal to get us across the JNI boundary, we can have several. I'm not sure if we should try and emulate the underlying API, or if it matters that we can have numerous hook call backs. I don't think it matters, but right now we have a (self-inflicted) test failure as a result. 2) However, if we have several, there is then no real difference between LinkButton.UriHook and Button.Clicked; if you want to do something special, just connect to Button.Clicked right? ... except that setting the URI hook (at least once) has the beneficial side effect of removing that LinkButton's default 'uri-hook' [which is to call gtk_show_uri()]. Which really seems the whole point. So maybe all we really need is a boolean property which is 'default-handler' or 'show' or 'use-default' [ie setUseDefault()], default true, or deactiveateDefaultUriHandler() or dontShowInBrowswerAndInsteadDoItYourself() :) with a tiny bit of JNI code to pass NULL to gtk_link_button_set_uri_hook() Then one can easily just use Button.Clicked for whatever behaviour you plan to have, and we could more or less scrap exposing the LinkButton.UriHook callback. 3) I added a custom URI handler in the Snapshot. After I did a call to setUriHook() the LinkButton that I had _not_ changed stopped working. That's gotta be bad :) finally 4) As a final stylistic question, I'm wondering if we shouldn't make setUriHook() be a connect() [and while we're at it, maybe we should have done that instead of TreeModelFilter's setVisibleCallback() originally? Sometimes I wonder about that] For what it's worth, we should try and be [self-]consistent; since it is setVisibleCallback() there, maybe it should be setUriHookCallback() here. or it should just be connect(). :( Hm. ++ Anyway, (3) is most likely a bug, so that'll need addressing. But also have a think about the broader design question. You've done some great work, and like Guillaume this week dug into the same horrid override case. But if we don't "need" it, then, well {shrug}. I look forward to your thoughts. AfC Sydney |
34 messages has been excluded from this view by a project administrator.
