Re: Java support in GTK/Gnome

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

> i just read through that document, and basically have a couple of issues
> with it. unfortunately i don't have Per Bothner's email handle and only
> got notified of this writeup through your email. i feel some more thoughtfull
> discussion from both parts needs to happen before we come up with a good
> solution. if you could forward this email, that'd be apprechiated.
> 
> on the signal part, dealing with interfaces ala:
> 
> public ButtonClickedListener
> {
>   public void clicked ();
> }
> public class Button extends Bin
> {
>   ...
>   public native void addClickedListener(ButtonClickedListener listener);
>   public native void removeClickedListener(ButtonClickedListener listener);
> }
> gnu::gtk::Button::addClickedListener(ButtonClickedListener* listener)
> {
>   gtk_signal_connect(GTK_OBJECT(this->peer),
>                       "clicked",
>                       GTK_SIGNAL_FUNC(button_click_cb),
>                       listener)
> }
> 
> will become quite cumbersome since you have the additonal overhead
> of add<SIGNAL>Listener remove<SIGNAL>Listener for ever signal on all
> objects

This is true. You get a pretty big set of functions this way.
You can't do the C style, since that is inherently non-type-safe,
but you can do something like:

 button->sig_clicked()->connect(button_click_cb);

[ This is the syntax from Inti in C++ ]

Implementing this in a straightforward way in Java also means
quite a bit of overhead for the binding writer; the C++ 
implementation uses plenty of template magic which isn't
there (probably luckily) in Java.

So, you'd probably have to write:

 public ButtonClickedSignal : Signal {
 }

In addition to ButtonClickedListener

>  and you don't support dynamically adding signals to existing
> classes this way.

Not an issue. (Adding signals to existing classes is a hack
we added because a) deriving new types to add new signals was hard
in C b) it was easy to do. In a decent Java binding, derivation
needs to be easy.)

> moving to something that'd allow button.connect ("clicked", listener);
> seems far more appealing.
> especially since there is more than just add/remove you could do
> with a connection, like temporarily blocking it which would additionally
> give blockClickedListener() and unblockClickedListener().
> besides that, there are obvious issues with object reference maintenance
> by passing listener as an anonymous pointer (but that might be due to
> the above excerpt being pseudo code), glib 1.3 will have sufficient
> support for real objects as connect data.

[ complexity, mumble, mumble, grumble, grumble ]

For Java, memory management of the Listener doesn't need complex
mechanisms. The Listener object is a pure Java object. The binding has
a responsibility for making sure that it is seen as referenced by the
GC as long as the connection exists.

Regards,
                                        Owen