Thread: [java-gnome-hackers] EntryCompletion work
Brought to you by:
afcowie
Menu
▾
▴
java-gnome-hackers
|
From: Andrew C. <an...@op...> - 2009-06-16 02:56:55
|
Guillaume sent me an large piece of work going a long way to exposing EntryCompletion for us. I gave it a first pass and found it surprisingly meaty. I haven't done a detailed review the API being presented, per se, but what I saw looked reasonable. Other experienced java-gnome hackers might care to offer their views. My branch from his work is at bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/entry-completion/ I've used EntryCompletion from pygtk, so this weekend I'll try porting that example to java-gnome and see how it goes. AfC Sydney |
|
From: Serkan K. <se...@ge...> - 2009-06-16 17:37:41
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 First of all, I should say that this is *great* work. gtk_entry_completion_set_match_func can be implemented with custom signal just as gtk_tree_model_filter_set_visible_func is implemented. You can examine TreeModelFilter and GtkTreeModelFilterOverride to see how its implemented. Handler for cursor-on-match is also missing, I think you know how to handle the TreeIter by now, so that can also be covered for completeness. By the way the example works on the whole content of the entry. Is it possible to hint for multiple words breaking the text with whitespece characters? - -- Sincerely, Serkan KABA Gentoo Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko32FsACgkQRh6X64ivZaIKFgCdEFCggjgPJ+9tw+B2hNKnrDBD Y2oAnRutpB9S3fa++JmHxBKnACwWmYr3 =fJgw -----END PGP SIGNATURE----- |
|
From: Serkan K. <se...@ge...> - 2009-06-16 17:43:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 One more issue I found out, the example doesn't terminate upon closure. - -- Sincerely, Serkan KABA Gentoo Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko32a4ACgkQRh6X64ivZaKx4QCcDfCwOH44Wa/4WI191BY4W4G8 wYgAn1UCoJ29LdV+kOgaqutyJmEcp9Z0 =dAIt -----END PGP SIGNATURE----- |
|
From: Serkan K. <se...@ge...> - 2009-06-17 03:19:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It was forgotton because the signal was introduced in 2.12 and our defs file was outdated. - -- Sincerely, Serkan KABA Gentoo Developer -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko4YMIACgkQRh6X64ivZaI3sgCfVUx9NJ0U3DBcMCA6OjuUdvh3 uVIAn0bog7Zc7HQYpgttBJbxFW3StAoo =C9TQ -----END PGP SIGNATURE----- |
|
From: Guillaume M. <res...@gm...> - 2009-06-24 19:22:37
Attachments:
completion-match-func.diff
|
I'm currently working on an implementation of the gtk_entry_completion_set_match_func() function but it still doesn't work. I got a warning during the code compilation and an error about a TreeIter assertion. Here is the compilation warning: GCC src/bindings/org/gnome/gtk/GtkEntryCompletionOverride.c src/bindings/org/gnome/gtk/GtkEntryCompletionOverride.c: In function ‘Java_org_gnome_gtk_GtkEntryCompletionOverride_gtk_1entry_1completion_1set_1match_1func’: src/bindings/org/gnome/gtk/GtkEntryCompletionOverride.c:76: attention : passing argument 2 of ‘gtk_entry_completion_set_match_func’ from incompatible pointer type And now the error when I try to use the implemented signal and methods: Exception in thread "main" org.gnome.glib.FatalError: Gtk-CRITICAL gtk_list_store_get_value: assertion `VALID_ITER (iter, list_store)' failed It appends when it tries to build the completion list so when the match_func is called. I attach a diff file to make you able to view my change. Maybe someone will find a way to fix the problem. 2009/6/17 Serkan Kaba <se...@ge...> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It was forgotton because the signal was introduced in 2.12 and our defs > file was outdated. > > - -- > Sincerely, > Serkan KABA > Gentoo Developer > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAko4YMIACgkQRh6X64ivZaI3sgCfVUx9NJ0U3DBcMCA6OjuUdvh3 > uVIAn0bog7Zc7HQYpgttBJbxFW3StAoo > =C9TQ > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > java-gnome-hackers mailing list > jav...@li... > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers > -- Guillaume Mazoyer (Respawner) - http://www.respawner.fr/ -- Guillaume Mazoyer (Respawner) - http://www.respawner.fr/ |
|
From: Serkan K. <se...@ge...> - 2009-06-24 20:27:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Did you try what we have discussed yesterday a) Defining the signal as having 3 params (I suppose iter is starving at the end of the parameter list) b) Dropping the second Entry param in the signal. - -- Sincerely, Serkan KABA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpCjAkACgkQRh6X64ivZaKDMACcDeUJnsYodZ/jsLSJWu/bHYvS mHoAn3qvtK+sEpkRLGBcaOfYf07nmgOC =BX24 -----END PGP SIGNATURE----- |
|
From: Andrew C. <an...@op...> - 2009-06-25 01:12:12
|
On Wed, 2009-06-24 at 21:22 +0200, Guillaume Mazoyer wrote:
> I attach a diff
Could you send a patch bundle? [then other people (like me :))] can
merge your branch into their own branches and try and duplicate the
problem — and maybe even contribute a fix.
While you're at it, please make sure to include the unit test that
you're using to exhibit this problem.
++
The type for NULL terminated strings in GLib is G_TYPE_STRING.
++
> src/bindings/org/gnome/gtk/GtkEntryCompletionOverride.c: In function
> ‘Java_org_gnome_gtk_GtkEntryCompletionOverride_gtk_1entry_1completion_1set_1match_1func’:
> src/bindings/org/gnome/gtk/GtkEntryCompletionOverride.c:76:
> attention : passing argument 2 of
> ‘gtk_entry_completion_set_match_func’ from incompatible pointer type
I'm guessing this is coming from
> + // call function
> + gtk_entry_completion_set_match_func(self, emit_match, self, NULL);
if so, that means that you've got the signature of emit_match() wrong.
It needs to be (*GtkEntryCompletionMatchFunc) which is
gboolean
something(
GtkEntryCompletion *completion,
const gchar *key,
GtkTreeIter *iter,
gpointer user_data)
{
}
and you have
+gboolean
+emit_match
+(
+ GtkEntryCompletion *source,
+ gchar *key,
+ GtkTreeIter *iter,
+ gpointer instance
+)
So I'd guess that the missing const qualifier is the reason you're
getting a warning.
++
> + gtk_entry_completion_set_match_func(self, emit_match, self, NULL);
Why are passing "self" as the user_data parameter?
I'm guessing the answer to that is that copy & paste has bit you. The
comment "note 2" in GtkTreeModelFilterOverride.c does not apply here.
So you probably want:
gtk_entry_completion_set_match_func(self, emit_match, NULL, NULL);
and then I'm guessing:
g_signal_emit_by_name(source, "match", key, iter, &result);
up above in emit_match(). You will note that what you have now has one
more parameter.
g_signal_emit_by_name(GTK_ENTRY_COMPLETION(instance), "match", source, key, iter, &result);
which would most certainly cause things to break if wrong.
++
It's things like this that make you begin to appreciate just how
amazingly helpful a static strongly-typed language like Java is. We Java
developers tend not to think about it. But when I try to do the "same"
stuff in C, and you realize what one had to put up with trying to get
signatures and function call arguments right, I really start to
appreciate java-gnome proxying all this crap for me.
As I said on IRC, you didn't pick an easy one. This is probably the most
complicated hand-written override we have. That said, you are probably
now getting a glimmer of why I'm so insistent in reusing the signal
handling code path - imagine going through this parameter nonsense by
hand every time you want to callback from C to Java. No thanks.
AfC
Sydney
|
|
From: Guillaume M. <res...@gm...> - 2009-06-25 16:24:49
Attachments:
signature.asc
|
I'm still stuck with another problem now. A NULL value is killing the example when I try to select a completion possibility.
Exception in thread "main" org.gnome.glib.FatalError: GLib-GObject-WARNING
invalid (NULL) pointer instance
at org.gnome.gtk.GtkMain.gtk_main(Native Method)
at org.gnome.gtk.GtkMain.main(GtkMain.java:57)
at org.gnome.gtk.Gtk.main(Gtk.java:95)
at ExampleEntryCompletion.main(ExampleEntryCompletion.java:205)
By the way, just by curiosity, I add a "printf("Key: %s\n", key);" in emit_match() method and I noticed that the signal is emitted (2 * size_of_completion_list). Does someone know why?
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?
2009/6/25 Andrew Cowie <an...@op...>
On Wed, 2009-06-24 at 21:22 +0200, Guillaume Mazoyer wrote:
> I attach a diff
Could you send a patch bundle? [then other people (like me :))] can
merge your branch into their own branches and try and duplicate the
problem — and maybe even contribute a fix.
While you're at it, please make sure to include the unit test that
you're using to exhibit this problem.
++
The type for NULL terminated strings in GLib is G_TYPE_STRING.
++
> src/bindings/org/gnome/gtk/GtkEntryCompletionOverride.c: In function
> ‘Java_org_gnome_gtk_GtkEntryCompletionOverride_gtk_1entry_1completion_1set_1match_1func’:
> src/bindings/org/gnome/gtk/GtkEntryCompletionOverride.c:76:
> attention : passing argument 2 of
> ‘gtk_entry_completion_set_match_func’ from incompatible pointer type
I'm guessing this is coming from
> + // call function
> + gtk_entry_completion_set_match_func(self, emit_match, self, NULL);
if so, that means that you've got the signature of emit_match() wrong.
It needs to be (*GtkEntryCompletionMatchFunc) which is
gboolean
something(
GtkEntryCompletion *completion,
const gchar *key,
GtkTreeIter *iter,
gpointer user_data)
{
}
and you have
+gboolean
+emit_match
+(
+ GtkEntryCompletion *source,
+ gchar *key,
+ GtkTreeIter *iter,
+ gpointer instance
+)
So I'd guess that the missing const qualifier is the reason you're
getting a warning.
++
> + gtk_entry_completion_set_match_func(self, emit_match, self, NULL);
Why are passing "self" as the user_data parameter?
I'm guessing the answer to that is that copy & paste has bit you. The
comment "note 2" in GtkTreeModelFilterOverride.c does not apply here.
So you probably want:
gtk_entry_completion_set_match_func(self, emit_match, NULL, NULL);
and then I'm guessing:
g_signal_emit_by_name(source, "match", key, iter, &result);
up above in emit_match(). You will note that what you have now has one
more parameter.
g_signal_emit_by_name(GTK_ENTRY_COMPLETION(instance), "match", source, key, iter, &result);
which would most certainly cause things to break if wrong.
++
It's things like this that make you begin to appreciate just how
amazingly helpful a static strongly-typed language like Java is. We Java
developers tend not to think about it. But when I try to do the "same"
stuff in C, and you realize what one had to put up with trying to get
signatures and function call arguments right, I really start to
appreciate java-gnome proxying all this crap for me.
As I said on IRC, you didn't pick an easy one. This is probably the most
complicated hand-written override we have. That said, you are probably
now getting a glimmer of why I'm so insistent in reusing the signal
handling code path - imagine going through this parameter nonsense by
hand every time you want to callback from C to Java. No thanks.
AfC
Sydney
------------------------------------------------------------------------------
_______________________________________________
java-gnome-hackers mailing list
jav...@li...
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
--
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: Guillaume M. <res...@gm...> - 2009-07-15 13:03:35
Attachments:
signature.asc
|
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/ |
×
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