Thread: [java-gnome-hackers] Looking for contributors for my incomplete Java-Gnome Bazaar branches
Brought to you by:
afcowie
Menu
▾
▴
java-gnome-hackers
|
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: Guillaume M. <res...@gm...> - 2009-07-27 19:37:29
Attachments:
signature.asc
|
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: 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: 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 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: 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: Guillaume M. <res...@gm...> - 2009-08-23 12:51:18
|
Since few days/weeks, I'm trying to keep some of the Serkan's branches alive. > 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. VTE branch [bzr/java-gnome/hackers/guillaume/vte/] is in progress. I added all methods but there is still a lot of documentation to do. > 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. Libsexy branch [bzr/java-gnome/hackers/guillaume/libsexy/] is also one of the branch I continue to work on. I guess It's pretty close to be finished. I did all the missing code and comments, wrote some examples and snapshots. I still must write test cases and everything should be ready after that. > 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. I think I finished to work on the linkbutton [bzr/java-gnome/hackers/guillaume/linkbutton/] branch. Serkan's did a lot of work on it. I just added comments, wrote an example and added email and url callbacks for AboutDialog. I'm not sure it is ready to be merged but (to Andrew) feel free to pull it and take a look. -- Guillaume Mazoyer - http://www.respawner.fr/ |
|
From: Andrew C. <an...@op...> - 2009-08-26 06:53:32
|
On Sun, 2009-08-23 at 14:51 +0200, Guillaume Mazoyer wrote: > I think I finished to work on the linkbutton So I just discovered the hard way that Serkan didn't merge the 'linkbutton' improvements I made in June into his branch. :( Guillaume, I merged your 'linkbutton' into mine; if you could in turn merge (or pull) 'hackers/andrew/linkbutton' into yours hopefully it'll be clean. You'll notice I wrote some tests that are failing. Perhaps you can see if you can figure out what wrong assumptions we're making about LinkButton's behaviour. AfC Sydney |
|
From: Guillaume M. <res...@gm...> - 2009-09-01 16:34:41
|
Hello, > Guillaume, I merged your 'linkbutton' into mine; if you could in turn > merge (or pull) 'hackers/andrew/linkbutton' into yours hopefully it'll > be clean. Done. > You'll notice I wrote some tests that are failing. Perhaps you can see > if you can figure out what wrong assumptions we're making about > LinkButton's behaviour. About the failing tests, I did some investigations to know more about the "gtk_link_button_set_uri_hook" method. I eventually wrote an example in C and its Java equivalent. When the GtkLinkButton (in C) is pressed, there is *no* "clicked" signal emitted (that is a little weird?) but in Java this signal is still emitted. So I guess the "gtk_link_button_set_uri_hook" callback totally replaces the "clicked" signal callback. With the current state of the "linkbutton" branch, we can do two different things with the "gtk_link_button_set_uri_hook" and the "clicked" signal, so maybe I should correct the current LinkButton behavior (how?) to make it act like the official GtkLinkButton does. -- Guillaume Mazoyer - http://www.respawner.fr/ |
|
From: Andrew C. <an...@op...> - 2009-09-01 23:12:31
|
On Tue, 2009-09-01 at 18:34 +0200, Guillaume Mazoyer wrote: > When the GtkLinkButton (in C) is pressed, there is *no* "clicked" signal > emitted (that is a little weird?) Presumably the C implementation in gtk/gtklinkbutton.c connects to the "clicked" signal and, having received it, blocks it from further emission. [though the internal detail of how they may be very different] > but in Java this signal is still > emitted. Perhaps because we're connecting before the [default] handler installed by GtkLinkButton? Still, you should have been able to duplicate the effect in C. Can you paste your C and Java test code somewhere? AfC Sydney |
|
From: Guillaume M. <res...@gm...> - 2009-09-02 12:31:48
|
Hello, > Can you paste your C and Java test code somewhere? Java example: http://respawner.pastebin.com/m10695646 C example: http://respawner.pastebin.com/d6107fe80 C files for the "clicked" callback: http://respawner.pastebin.com/d5e5a0647 http://respawner.pastebin.com/d287b66ab -- Guillaume Mazoyer - http://www.respawner.fr/ |
|
From: Guillaume M. <res...@gm...> - 2009-09-02 18:38:17
|
Hello, I continue my investigation. In my last to mails I was wrong. When we click on a GtkLinkButton both of the "clicked" and "gtk_link_button_set_uri_hook()" callbacks are used. The current branch acts like GTK does except for one thing. As you supposed, when we used the "gtk_link_button_set_uri_hook()" method twice the second callback *should replace* the first one so I guess it is the only thing which should be corrected. -- Guillaume Mazoyer - http://www.respawner.fr/ |
|
From: Guillaume M. <res...@gm...> - 2009-09-13 11:57:10
|
Hello, I found a way to "unset" the previous URI hook in the GtkLinkButton class but using it in the JNI side still does not work. And now, I'm a bit lost. In order to come back to the default GtkLinkButton behavior, we have to use the "gtk_link_button_set_uri_hook()" but with 3 NULL arguments. >> gtk_link_button_set_uri_hook(NULL, NULL, NULL); In this way, even if this method has been used before, a click on the button will simply open the given URI with the with the showUri(URI) method. I tried to use this to correct the our default LinkButton behavior but it still doesn't work. I guess it is due to the fact that there is no reference to the GtkLinkButton given to the "gtk_link_button_set_uri_hook()" method. Is it possible to fix that? I guess but I don't know how... -- Guillaume Mazoyer - http://www.respawner.fr/ |
|
From: Andrew C. <an...@op...> - 2009-09-14 02:13:34
|
On Sun, 2009-09-13 at 13:56 +0200, Guillaume Mazoyer wrote: > I found a way to "unset" the previous URI hook in the GtkLinkButton > class but using it in the JNI side still does not work. And now, I'm a > bit lost. Is this code on your 'linkbutton' branch? Anyway, I think we're pretty close now, so next time we catch up together online let's see if we can figure it out together. AfC Sydney |
|
From: Guillaume M. <res...@gm...> - 2009-09-14 11:38:03
|
Hello, > Is this code on your 'linkbutton' branch? No, it is not. Since it does not work I chose to not commit it. > Anyway, I think we're pretty close now, so next time we catch up > together online let's see if we can figure it out together. I think so. I hope we can finish this work soon. -- Guillaume Mazoyer - http://www.respawner.fr/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X