java-gnome-hackers

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

[Stefan S. <ste...@gm...>]

Hi java-gnome hackers,

currently I am working on a personal application using java-gnome and I
found some parts of the toolkit that I need which are not yet exposed. 

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". From what I can see, this
parameter is quite useless because the new page can also be obtained
from the page_num parameter. In gtk# this type is even deprecated.

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

Does anyone have an idea what I can do about this parameter? Or can we
omit this parameter completely in the public API?

The other thing I am interested in is GtkSourceView. Is anyone working
or planning to work on coverage for this library?

	Stefan


[1]
http://library.gnome.org/devel/gtk/stable/GtkNotebook.html#GtkNotebook-switch-page

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

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

[Stefan S. <ste...@gm...>]

On Sat, 2009-02-14 at 22:03 +1100, Andrew Cowie wrote:
> That _might_ work. I kinda doubt it, actually, but it might do as a
> kludge. A patch bundle to this effect is attached.

Unfortunately changing the parameter to glong did not work. I get a
"java.lang.NoSuchMethodError: receiveSwitchPage" when connecting to the
signal.

> 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.

I also tried to create NotebookPage as new type but it resulted in a
NoSuchMethodError as well. Here is the defs file that I used:

(define-boxed NotebookPage
  (in-module "Gtk")
  (c-name "GtkNotebookPage")
  (gtype-id "G_TYPE_POINTER")
)

Maybe something is missing or wrong, especially I do not know what to
use for copy-func and release-func.

	Stefan

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

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

On Sun, 2009-02-15 at 13:55 +0100, Stefan Schweizer wrote:
> On Sat, 2009-02-14 at 22:03 +1100, Andrew Cowie wrote:
> > That _might_ work. I kinda doubt it, actually, but it might do as a
> > kludge. A patch bundle to this effect is attached.
> 
> Unfortunately changing the parameter to glong did not work. I get a
> "java.lang.NoSuchMethodError: receiveSwitchPage" when connecting to the
> signal.

Do you have a TestCase that runs through this? 

testReactingToCursorPositionChanges() in ValidateTextBuffer is an
example of hooking up a signal that reacts to a programmatic event. If
you coded up something like that and sent us a bundle with it, then we
could see what you're seeing.

As for the NoSuchMethodError, that is what happens when the signature
doesn't precisely match. Java VMs are very precise that way. You might
have had something incorrect on the other side.

If you manually remove the comments hiding lines 521-522 in
src/jni/bindings_java_signal.c you'll see some debug info about this.

For example, GtkWidget.receiveDeleteEvent() is invoked with a signature
of

(Lorg/gnome/glib/Signal;JJ)Z

with the first J being the long for the pointer address of Widget
"source", and the second J being the long for the boxed Event "event". I
imagine you'll find it will attempt to find a method called
receiveSwitchPage() with a signature of

(Lorg/gnome/glib/Signal;JJI)V

if you change to glong like I suggested. So then the question would be
why the generated receiver method doesn't have a matching signature.

Actually, the real question is what *actually* it is being invoked as
(since you can't change what GLib thinks the parameters are); presumably
it's not what I speculated above since presumably having changed that
parameter to glong would have caused a receive of that signature no
problem.

Once you find out what is actually being composed, then can you come up
with something else for the .defs data that you can cause the signature
of the generated receiveSwitchPage() to match. Should be fairly straight
forward once you know what it's feeding you.

AfC
Sydney

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

[Stefan S. <ste...@gm...>]

Thanks for your help, Andrew. I am attaching a bundle with what I have
so far, also a test that currently fails.

Uncommenting the debug message reveals the following:
Java method receiveSwitchPage
with signature (Lorg/gnome/glib/Signal;JI)V
in class FIXME
to handle signal switch-page

So the page parameter is missing? I have no idea.

	Stefan

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

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

On Mon, 2009-02-16 at 20:30 +0100, Stefan Schweizer wrote:
> I am attaching a bundle with what I have
> so far, also a test that currently fails.

You're a star.

> Uncommenting the debug message reveals the following:
> Java method receiveSwitchPage
> with signature (Lorg/gnome/glib/Signal;JI)V
> to handle signal switch-page
> 
> So the page parameter is missing? I have no idea.

Wow. That is weird. Of all the things I expected to see, that was
certainly not it.

I mean, in essence, that's what we _want_ it to be, right? With that as
the signature we're being handed we could just edit that parameter out
of the (define-virtual) and it'd work, and no need for the private
handler class anything to trim the parameter. Which would be great.

So we're done!

Except for one thing.

I don't know why we're getting handed a parameter sequence that is
resulting in us calculating that signature. Where's the GtkNotebookPage*
parameter?

My guesses are that either,

a) something in GTK is acting to hide that parameter (unlikely, given
that pygtk see it). I read the source code in GTK for gtk/gtknotebook.c
and I don't see anything changing the signal at registration or emission
time.

or

b) something in our signal marshaling code is choking and causing us to
skip that parameter. That'd be good if we were doing it on purpose.

If we can work out which it is, then we can probably sort this out.

There's still a lingering doubt about whether this signal is actually
supposed to be public. Unfortunately GLib × gtkdoc doesn't have a
mechanism for not presenting signals that are actually internal.

AfC
Sydney

P.S. No need to address me as well. I'm subscribed to the mailing list.



> 
> 	Stefan
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________ java-gnome-hackers mailing list jav...@li... https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
-- 
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

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

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

On Tue, 2009-02-17 at 13:42 +1100, Andrew Cowie wrote:
> My guesses are

Ok, it's mostly us, with a tinsy bit of GTK:

> a) something GTK is doing

They marshal the parameter as a G_TYPE_POINTER which is as about as
opaque and unusable as you can get. Certainly it is not the
GtkNotebookPage* that they said it was in the .defs data.

> b) something in our signal marshaling code is choking and causing us to
> skip that parameter. That'd be good if we were doing it on purpose.

But we're not. We were skipping it as a fallback in a default block in a
switch statement, and worse losing track of the warning message. That's
all bad, more or less, so I did something about it. Building on Stefan's
work,
bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/notebook-signals/

Stefan, if you take that branch and do the work to document the public
API you wish to expose and to finish up the test case you started on,
then I'd say we can merge it to 'mainline' fairly quickly.

AfC
Sydney

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

[Stefan S. <ste...@gm...>]

On Tue, 2009-02-17 at 19:34 +1100, Andrew Cowie wrote:
> Stefan, if you take that branch and do the work to document the public
> API you wish to expose and to finish up the test case you started on,
> then I'd say we can merge it to 'mainline' fairly quickly.

I did the documentation and the test.

	Stefan

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

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

On Wed, 2009-02-18 at 00:10 +0100, Stefan Schweizer wrote:
> I did the documentation and the test.

Terrific!

Should you do work like this in the future, please add things like
@since tags. I took care of it for you this time - you've already put a
huge amount of work into this and it's otherwise ready. So,

Merged to 'mainline'.

Well done. Thanks for your persistence on this one.

AfC
Sydney