Re: [java-gnome-hackers] Adding switch-page signal

[Andrew C. <an...@op...>]

On Sat, 2009-02-14 at 10:50 +0100, Stefan Schweizer wrote:
> I would like to add the switch-page signal [1] of GtkNotebook but I got
> stuck. The generated interface has a FIXME data type for the page
> parameter which should be a GtkNotebookPage. The documentation says that
> it's an "opaque implementation detail".

Yup. Pretty awful of them to have exposed this in their public API.

[You often here us going on about how hard doing a language binding of a
GNOME library is; in particular, C sugar leaking as public interfaces is
common and horrid to deal with]

>  From what I can see, this
> parameter is quite useless

From what I can tell it is entirely an implementation detail internal to
GtkNotebook.


> I already tried to create a defs-file for GtkNotebookPage but did not
> know which parent class I should use.

Right. So, I think the right way to deal with this is:

        a) not to expose it,

and

        b) do whatever minimum kludging is necessary to let us marshal
        it successfully.

The pygtk docs give me thought in the right direction: they point out
that it's a gpointer and unusable. No kidding. Anyway,

So to achieve (a) we need to do a wrapper like is done any time we need
to change the signature of a signal handler callback interface. See the
TextBuffer.InsertText signal for a recent example of trimming off an
unnecessary parameter. Follow that pattern and you'll be able to lose
the 2nd parameter of the 'switch-page' signature.

Dealing with the not-public type (b) will be a little tougher. This is
where we'll have to do something bad to trick out our code generator
into doing something that we can then ignore with (a). Picking a
compatible type and changing the .defs data for the switch-page virtual
*might* work.

The worrisome part here is that it's not just a matter of casting like
the forward direction usually is, but rather ensuring that the args
placed on the call stack for a C -> Java invocation (as happens when we
marshal a signal) don't cause a large splat when that invoke happens.

Fortunately, by careful design we only pass primitives across the JNI
boundary, so it's entirely possible that anything that (still) results
in a jlong being passed across (ie, what we wrap pointers in) will work.

So maybe try:

=== modified file 'src/defs/GtkNotebook.defs'
--- src/defs/GtkNotebook.defs	2009-02-01 05:36:52 +0000
+++ src/defs/GtkNotebook.defs	2009-02-14 10:50:45 +0000
@@ -343,7 +343,7 @@
   (of-object "GtkNotebook")
   (return-type "none")
   (parameters
-    '("GtkNotebookPage*" "page")
+    '("glong" "page")
     '("guint" "page_num")
   )
 )

That _might_ work. I kinda doubt it, actually, but it might do as a
kludge. A patch bundle to this effect is attached.

Slightly better would be to define something that would automatically
result in 0L being passed back for that parameter, regardless of what
type it is.

Or, finally, the worst case scenario is that we have to create a new
Boxed type NotebookPage. THAT will certainly work, and indeed is the
most "proper" solution, although it'd be kinda silly to have to do so if
we can avoid it. I've been working fairly hard to get _rid_ of no-op
type declarations like this.

See how you go.

++

Bad GTK hackers, letting internal structs be publicly visible. Bad. No
milk bone for you today.

AfC
Sydney