Re: [java-gnome-hackers] EntryCompletion work

[Andrew C. <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