I spent some time looking at the Java-GNOME implementation this
 weekend, and had some concerns that I was pressed to write up.
 
 I"d divide my concerns into three main areas:
 
  - Events
  - Memory management
  - Completeness and consistency of the mapping
 
 Events
 ======
 
 There are two problems with signal handling ... one problem is that it
 is just clumsy:
 
   button.addListener (new ButtonListener () {
      public void buttonEvent (ButtonEvent event) {
          if (event.isOfType(ButtonEvent.Type.CLICK) {
            System.out.println("Button was clicked");
          }
      }
   });
 
 In Python, say, this is:
 
  def onClick (button):
     print "Button was clicked";
  
  button.connect ("clicked", onClick);
 
 Obviously, there is a syntax barrier for Java, but there is no real 
 reason it couldn"t be:
 
  button.connectClicked (new ButtonClickedListener () {
     public void run(Button button) {
       System.out.println("Button was clicked");
     }  
  }
 
 Creating one helper class for each signal might be a bit
 expensive... there are other cheaper mechanisms with less type
 safety. For example:
 
  button.connectClicked (new SignalListener () {
     public Object run(Object[] args) {
       System.out.println("Button was clicked");
       return null;
     }  
  }
 
 You could have convenience implementations predefined for common
 cases:
 
  button.connectDestroyEvent (new EventListener () {
     public boolean run(Widget widget, Event event) {
        // show a "save changes dialog
        return true;
     }
  }
 
  button.connectClicked (new SimpleListener () {
     public void run(Object object) {
        System.out.println("Button was clicked");
     }
  }
 
 Another approach would be to take the addEventHandler() approach
 that currently exists and extend it to use the closure data
 about argument types, so you could do something like:
 
  button.connectDestroyEvent (new Object () {
     public boolean destroyEvent(Widget widget, Event event) {
        // show a "save changes dialog
        return true;
     }
  }
 
 What *all* of these share is that there is an algorithmic mapping to
 the underlying signals. That is the second problem with the current
 approach; there is no way that someone familiar with the C or Python
 interface on an object can guess the way the Java events are set up on
 that object.
 
 Not only does this make things hard on people who already know a
 GTK+ from a different language or are reading documentation that uses
 a different language, it also makes it impossible to do automatic
 generation of language bindings.
 
 Memory Management
 =================
 
 One problem with memory management in gtk-java can be
 expressed with a simple grep command:
 
  libgtk-java$ find -name "*.c" | xargs grep g_object_unref
  libgtk-java$
 
 If I create a PangoLayout object through the java-gnome APIs,
 there is no way it will ever be freed.
 
 But this isn"t the only problem with memory management of 
 GObject ... 
 
  Window window = new Window (WindowType.TOPLEVEL);
  Button button = new Button ("Hello");
  window.add (button);
  window.remove (button);
  window.add (button);
 
 Will segfault or at least produce warnings as the underlying
 GtkObject is freed when the button is removed from the window
 and the Java object is left holding an invalid pointer.
 
 Fixing this, within the constraints of the JNI is admittedly not
 easy. In fact, I don"t know an entirely satisfactory way of doing so
 without extending GObject. (I"m going to propose such an addition to
 GObject for 2.8.) But you can do somewhat better. For example,
 the approach that gtk# takes is to use strong reference from
 the CLR object to the GObject and a weak reference in the 
 opposite direction. 
 
 (The main problem of this is "denaturation"...  if you drop the last
 reference to a language object that is a subclass of Button, then 
 if you get the object back from GTK+ what you get is a normal
 Button, not your subclass.)
 
 
 Completeness and Consistency of the Mapping
 ===========================================
 
 The Java-GNOME bindings seem largely done by hand. This approach
 is going to cause problems with both completeness and with
 consistency. A few examples:
 
  pango_layout_set_wrap()
  pango_layout_get_wrap()
  pango_layout_set_justify()
  pango_layout_get_justify()
  
 Are wrapped as:
 
  Layout.setWrapStyle()
  Layout.getWrapMode()
  Layout.setJustification()
  Layout.GetJustified()
 
 void pango_layout_set_markup            (PangoLayout    *layout,
                                          const char     *markup,
                                          int             length);
 void pango_layout_set_markup_with_accel (PangoLayout    *layout,
                                          const char     *markup,
             	                         int             length,
 		        	         gunichar        accel_marker,
                                          gunichar       *accel_char);
 are wrapped as:
 
 
   public void setMarkup(String markup);
   public void setMarkup(String markup,
   	                char   accelMarker); (*)
 
 While using overloading might make sense here, where did the accel_char
 return from set_markup_with_accel() go?
 
 These examples are from PangoLayout, which is probably newer and rawer
 then much of Java-GNOME (after all, you can"t free one), but there are
 problems elsewhere as well. (gdk.Window.getWindowAt, 
 gdk.Window.setTransientOf, for examples.)
 
 Any language binding is a compromise between sticking close to the
 library being bound and being truly natural in the language. 
 Conceptually, GTK+ is composed of two pieces:
  
  A) Pieces that are language bindable
  B) Pieces that are C specific convenience glue
 
 The goal of the GTK+ design is that everything *can* be done using
 only A). I think a good goal for any language binding is that piece
 A) is transformed into the language in a way that is completely
 algorithmic and predictable and then, as necessary, language specific
 glue is added to make up for piece B).
 
 The introspection facilities in Glib/GTK+-2.8 will provide a canonical
 description of the GTK+ interfaces. I think it would be good
 if Java-GNOME could be switched at that point to be primarily
 autogenerated from the introspection information.
 
 (*) Side note: char isn"t the right mapping for gunichar. It should
     be int instead. See:
 
 http://java.sun.com/developer/technicalArticles/Intl/Supplementary/
 
 [ Note: I"m not subscribed, so please Cc: me on any replies ]

			

 On 4/25/05, Owen Taylor <otaylor@re...> wrote:
 > I spent some time looking at the Java-GNOME implementation this
 > weekend, and had some concerns that I was pressed to write up.
 
 First of all I would like to thank you very much for taking the time
 to look at Java-GNOME and express your concerns.   There are numerous
 areas where these bindings need improvement (perhaps significant
 rewrite).  Over the life of this project it has been a constant struggle 
 trying to balance our need to improve the bindings, support our current
 users, and trying to stay somewhat current with the upstream libraries
 with our extremely limited developer resources.  Those who have been
 users of this project over that time will say that we have made constant
 steady (although slow) progress on all of those fronts.   Below I am 
 going to try to comment on several of the items you listed.
 
 > Events
 > ======
 > 
 > There are two problems with signal handling ... one problem is that it
 > is just clumsy:
 > 
 >   button.addListener (new ButtonListener () {
 >      public void buttonEvent (ButtonEvent event) {
 >          if (event.isOfType(ButtonEvent.Type.CLICK) {
 >            System.out.println("Button was clicked");
 >          }
 >      }
 >   });
 
 
 The history of event handling in Java-GNOME is important here.  
 My initial attempt at signal handling was quite similar to the C 
 implementation.  There was a collection of methods similar to:
 
 public native int addEventHandler(String name, String func, Object cbrecv)
 
 so the implementation for a button would be:
 
 public void onClick() {
   System.out.println("Button was clicked");
 }
 
 button.addEventHandler("clicked", "onClick", this);
 
 As Java developers started to use the bindings I received many 
 comments stating that the event handling was not very "javalike" 
 meaning it was not like awt or swing.  After taking a poll of the users
 it was obvious that the majority of Java developers liked the listener 
 approach to events.  I proceeded to add this new approach but have 
 never deprecated the old style of event handling. 
 
 > Obviously, there is a syntax barrier for Java, but there is no real
 > reason it couldn"t be:
 > 
 >  button.connectClicked (new ButtonClickedListener () {
 >     public void run(Button button) {
 >       System.out.println("Button was clicked");
 >     }
 >  }
 > 
 > Creating one helper class for each signal might be a bit
 > expensive... there are other cheaper mechanisms with less type
 > safety. For example:
 > 
 >  button.connectClicked (new SignalListener () {
 >     public Object run(Object[] args) {
 >       System.out.println("Button was clicked");
 >       return null;
 >     }
 >  }
 > 
 > You could have convenience implementations predefined for common
 > cases:
 > 
 >  button.connectDestroyEvent (new EventListener () {
 >     public boolean run(Widget widget, Event event) {
 >        // show a "save changes dialog
 >        return true;
 >     }
 >  }
 > 
 >  button.connectClicked (new SimpleListener () {
 >     public void run(Object object) {
 >        System.out.println("Button was clicked");
 >     }
 >  }
 > 
 > Another approach would be to take the addEventHandler() approach
 > that currently exists and extend it to use the closure data
 > about argument types, so you could do something like:
 > 
 >  button.connectDestroyEvent (new Object () {
 >     public boolean destroyEvent(Widget widget, Event event) {
 >        // show a "save changes dialog
 >        return true;
 >     }
 >  }
 
 These are all interesting ideas.
 
 > What *all* of these share is that there is an algorithmic mapping to
 > the underlying signals. That is the second problem with the current
 > approach; there is no way that someone familiar with the C or Python
 > interface on an object can guess the way the Java events are set up on
 > that object.
 > 
 > Not only does this make things hard on people who already know a
 > GTK+ from a different language or are reading documentation that uses
 > a different language, it also makes it impossible to do automatic
 > generation of language bindings.
 
 The automatic generation of language bindings is an interesting topic.
 Java-GNOME started out five years ago by generating all code (Java and 
 JNI).  At that time there were many inconsistencies in gtk, etc (and my
 understand of those libraries was even less than it is today).  Over time 
 the code generation became so complex (to handle all of the exceptions)
 that it was not maintainable.  Eventually I made the change over to 
 manually writing the code.  Since that time the upstream libraries have 
 matured and I am quite interested in the introspection work being done.  
 I must admit that I do not have enough time to be directly involved or
 contribute ideas.  I would like to be more involved but I guess it is not to 
 be.  At some point I will find the time to learn the new API and try to see
 how it fits with Java-GNOME.
 
 
 > Memory Management
 > =================
 > 
 > One problem with memory management in gtk-java can be
 > expressed with a simple grep command:
 > 
 >  libgtk-java$ find -name "*.c" | xargs grep g_object_unref
 >  libgtk-java$
 > 
 > If I create a PangoLayout object through the java-gnome APIs,
 > there is no way it will ever be freed.
 
 The original idea here (quite naive perhaps) was to have a running
 Java-GNOME application behave like a GTK C application with a thin
 Java veneer.  For GObjects we should construct them via their
 _new method and allow GTK to reclaim their memory when their 
 container destroyed them.  For objects that did not inherit from GObject
 we tried to research to determine who managed the memory
 (was this a struct returned from a Widget where the Widget
 was responsible for managing the memory or was the caller
 responsible for managing the memory).   I know we got some of
 this wrong.
 
 > But this isn"t the only problem with memory management of
 > GObject ...
 > 
 >  Window window = new Window (WindowType.TOPLEVEL);
 >  Button button = new Button ("Hello");
 >  window.add (button);
 >  window.remove (button);
 >  window.add (button);
 > 
 > Will segfault or at least produce warnings as the underlying
 > GtkObject is freed when the button is removed from the window
 > and the Java object is left holding an invalid pointer.
 
 This is a problem we have discussed on several occasions.  Two
 issues have caused us to not address this problem; (1) we have
 not come up with a design that we feel is clean (robust?) and
 (2) we have not had the manpower to undertake such a massive
 change (the vast majority of the time this project has had 1-2
 part-time developers).
 
 > Fixing this, within the constraints of the JNI is admittedly not
 > easy. In fact, I don"t know an entirely satisfactory way of doing so
 > without extending GObject. (I"m going to propose such an addition to
 > GObject for 2.8.) But you can do somewhat better. For example,
 > the approach that gtk# takes is to use strong reference from
 > the CLR object to the GObject and a weak reference in the
 > opposite direction.
 > 
 > (The main problem of this is "denaturation"...  if you drop the last
 > reference to a language object that is a subclass of Button, then
 > if you get the object back from GTK+ what you get is a normal
 > Button, not your subclass.)
 
 Please - lets discuss this idea further.
 
 
 > Completeness and Consistency of the Mapping
 > ===========================================
 > 
 > The Java-GNOME bindings seem largely done by hand. This approach
 > is going to cause problems with both completeness and with
 > consistency. A few examples:
 > 
 >  pango_layout_set_wrap()
 >  pango_layout_get_wrap()
 >  pango_layout_set_justify()
 >  pango_layout_get_justify()
 > 
 > Are wrapped as:
 > 
 >  Layout.setWrapStyle()
 >  Layout.getWrapMode()
 >  Layout.setJustification()
 >  Layout.GetJustified()
 > 
 > void pango_layout_set_markup            (PangoLayout    *layout,
 >                                          const char     *markup,
 >                                          int             length);
 > void pango_layout_set_markup_with_accel (PangoLayout    *layout,
 >                                          const char     *markup,
 >                                          int             length,
 >                                          gunichar        accel_marker,
 >                                          gunichar       *accel_char);
 > are wrapped as:
 > 
 >   public void setMarkup(String markup);
 >   public void setMarkup(String markup,
 >                         char   accelMarker); (*)
 
 I am sad to see this (at the same time I must admit that I
 laughed when I saw the example you provided - it is sooo
 bad).  There has been a lot of work over the past couple
 of years trying to cleanup the bindings.  One of the first
 areas you would look at (pango) is one of the last areas 
 to be addressed (largely due to my shallow understanding
 of how pango works).  atk and pango are mentioned as
 two areas of focus during our current development cycle.
 We know there is still more work to do but I feel we are
 making good progress on this issue.
 
 > 
 > While using overloading might make sense here, where did the accel_char
 > return from set_markup_with_accel() go?
 > 
 > These examples are from PangoLayout, which is probably newer and rawer
 > then much of Java-GNOME (after all, you can"t free one), but there are
 > problems elsewhere as well. (gdk.Window.getWindowAt,
 > gdk.Window.setTransientOf, for examples.)
 > 
 > Any language binding is a compromise between sticking close to the
 > library being bound and being truly natural in the language.
 > Conceptually, GTK+ is composed of two pieces:
 > 
 >  A) Pieces that are language bindable
 >  B) Pieces that are C specific convenience glue
 > 
 > The goal of the GTK+ design is that everything *can* be done using
 > only A). I think a good goal for any language binding is that piece
 > A) is transformed into the language in a way that is completely
 > algorithmic and predictable and then, as necessary, language specific
 > glue is added to make up for piece B).
 > 
 > The introspection facilities in Glib/GTK+-2.8 will provide a canonical
 > description of the GTK+ interfaces. I think it would be good
 > if Java-GNOME could be switched at that point to be primarily
 > autogenerated from the introspection information.
 > 
 > (*) Side note: char isn"t the right mapping for gunichar. It should
 >     be int instead. See:
 > 
 > http://java.sun.com/developer/technicalArticles/Intl/Supplementary/
 > 
 > [ Note: I"m not subscribed, so please Cc: me on any replies ]
 > 
 > 
 -- 
 Jeffrey Morgan

 
 
 
 On Mon, 2005-04-25 at 21:42 -0400, Jeff Morgan wrote:
 
 > > Events
 > > ======
 > > 
 > > There are two problems with signal handling ... one problem is that it
 > > is just clumsy:
 > > 
 > >   button.addListener (new ButtonListener () {
 > >      public void buttonEvent (ButtonEvent event) {
 > >          if (event.isOfType(ButtonEvent.Type.CLICK) {
 > >            System.out.println("Button was clicked");
 > >          }
 > >      }
 > >   });
 > 
 > 
 > The history of event handling in Java-GNOME is important here.  
 > My initial attempt at signal handling was quite similar to the C 
 > implementation.  There was a collection of methods similar to:
 > 
 > public native int addEventHandler(String name, String func, Object cbrecv)
 > 
 > so the implementation for a button would be:
 > 
 > public void onClick() {
 >   System.out.println("Button was clicked");
 > }
 > 
 > button.addEventHandler("clicked", "onClick", this);
 > 
 > As Java developers started to use the bindings I received many 
 > comments stating that the event handling was not very "javalike" 
 > meaning it was not like awt or swing.  After taking a poll of the users
 > it was obvious that the majority of Java developers liked the listener 
 > approach to events.  I proceeded to add this new approach but have 
 > never deprecated the old style of event handling. 
 
 Not that I really know much about what is "javalike", but it does
 make sense to me that a typesafe approach using listener interfaces
 and delegate objects fits in better with Java expectations.
 
 However, starting from that point, there seems to be a fair bit
 of wriggle room to do create something that is both convenient and
 can be mapped consistently onto the GTK+ signal system.
 
 I don"t think signal handlers in GTK+ can work exactly like event
 handlers in Swing ... even to the point of the name ... "Event"
 means something very specific in GDK and reusing it for something
 else is going to confuse things. But neither does widget layout
 in GTK+ work exactly like widget layout in Swing.
 
 > > Not only does this make things hard on people who already know a
 > > GTK+ from a different language or are reading documentation that uses
 > > a different language, it also makes it impossible to do automatic
 > > generation of language bindings.
 > 
 > The automatic generation of language bindings is an interesting topic.
 > Java-GNOME started out five years ago by generating all code (Java and 
 > JNI).  At that time there were many inconsistencies in gtk, etc (and my
 > understand of those libraries was even less than it is today).  Over time 
 > the code generation became so complex (to handle all of the exceptions)
 > that it was not maintainable.  Eventually I made the change over to 
 > manually writing the code.  Since that time the upstream libraries have 
 > matured and I am quite interested in the introspection work being done.  
 > I must admit that I do not have enough time to be directly involved or
 > contribute ideas.  I would like to be more involved but I guess it is not to 
 > be.  At some point I will find the time to learn the new API and try to see
 > how it fits with Java-GNOME.
 
 What I hope we can do with the introspection work is turn the work
 of writing a language binding from one of writing a large amount of
 tedious code into one of writing a small amount of difficult code :-)
 
 While the initial work may be harder, hopefully the job of continued
 maintenance will be much less.
 
 > > Memory Management
 > > =================
 > > 
 > > One problem with memory management in gtk-java can be
 > > expressed with a simple grep command:
 > > 
 > >  libgtk-java$ find -name "*.c" | xargs grep g_object_unref
 > >  libgtk-java$
 > > 
 > > If I create a PangoLayout object through the java-gnome APIs,
 > > there is no way it will ever be freed.
 > 
 > The original idea here (quite naive perhaps) was to have a running
 > Java-GNOME application behave like a GTK C application with a thin
 > Java veneer.  For GObjects we should construct them via their
 > _new method and allow GTK to reclaim their memory when their 
 > container destroyed them.  For objects that did not inherit from GObject
 > we tried to research to determine who managed the memory
 > (was this a struct returned from a Widget where the Widget
 > was responsible for managing the memory or was the caller
 > responsible for managing the memory).   I know we got some of
 > this wrong.
 
 Hmm, as long as the C program doesn"t require g_object_ref/unref
 this works. But for something like PangoLayout, or GdkGC, or 
 many other non-widget GObjects, a C program needs to call
 ref() and unref() itself to manage the memory. 
 
 Now, you could bind g_object_unref() and expose it to Java 
 programs, but all the other language bindings I"m familiar with 
 have tried to make things more automatic (and thus more robust)
 than that.
 
 > 
 > > But this isn"t the only problem with memory management of
 > > GObject ...
 > > 
 > >  Window window = new Window (WindowType.TOPLEVEL);
 > >  Button button = new Button ("Hello");
 > >  window.add (button);
 > >  window.remove (button);
 > >  window.add (button);
 > > 
 > > Will segfault or at least produce warnings as the underlying
 > > GtkObject is freed when the button is removed from the window
 > > and the Java object is left holding an invalid pointer.
 > 
 > This is a problem we have discussed on several occasions.  Two.
 > issues have caused us to not address this problem; (1) we have
 > not come up with a design that we feel is clean (robust?) and
 > (2) we have not had the manpower to undertake such a massive
 > change (the vast majority of the time this project has had 1-2
 > part-time developers).
 
 I think you could do some basic fixes for memory management of
 GObject without affecting most of your code.
 
 [...]
 
 > cy of the Mapping
 > > ===========================================
 > > 
 > > The Java-GNOME bindings seem largely done by hand. This approach
 > > is going to cause problems with both completeness and with
 > > consistency. A few examples:
 > > 
 > >  pango_layout_set_wrap()
 > >  pango_layout_get_wrap()
 > >  pango_layout_set_justify()
 > >  pango_layout_get_justify()
 > > 
 > > Are wrapped as:
 > > 
 > >  Layout.setWrapStyle()
 > >  Layout.getWrapMode()
 > >  Layout.setJustification()
 > >  Layout.GetJustified()
 > > 
 > > void pango_layout_set_markup            (PangoLayout    *layout,
 > >                                          const char     *markup,
 > >                                          int             length);
 > > void pango_layout_set_markup_with_accel (PangoLayout    *layout,
 > >                                          const char     *markup,
 > >                                          int             length,
 > >                                          gunichar        accel_marker,
 > >                                          gunichar       *accel_char);
 > > are wrapped as:
 > > 
 > >   public void setMarkup(String markup);
 > >   public void setMarkup(String markup,
 > >                         char   accelMarker); (*)
 > 
 > I am sad to see this (at the same time I must admit that I
 > laughed when I saw the example you provided - it is sooo
 > bad).  There has been a lot of work over the past couple
 > of years trying to cleanup the bindings.  One of the first
 > areas you would look at (pango) is one of the last areas 
 > to be addressed (largely due to my shallow understanding
 > of how pango works).  atk and pango are mentioned as
 > two areas of focus during our current development cycle.
 > We know there is still more work to do but I feel we are
 > making good progress on this issue.
 
 I don"t mean to pick on PangoLayout in particular, it just happened
 to be the class I picked to review, since I have it more memorized
 than much of the rest of GTK.
 
 My point was mostly that with a manually maintained binding, you
 have to become an expert in everybody"s favorite widget ... with
 more automation, hopefully the PangoLayout binding can be right
 with almost no specific work.
 
 Regards,
 						Owen

			

 On 4/26/05, Owen Taylor <otaylor@re...> wrote:
 > On Mon, 2005-04-25 at 21:42 -0400, Jeff Morgan wrote:
 > > The automatic generation of language bindings is an interesting topic.
 > > Java-GNOME started out five years ago by generating all code (Java and
 > > JNI).  At that time there were many inconsistencies in gtk, etc (and my
 > > understand of those libraries was even less than it is today).  Over time
 > > the code generation became so complex (to handle all of the exceptions)
 > > that it was not maintainable.  Eventually I made the change over to
 > > manually writing the code.  Since that time the upstream libraries have
 > > matured and I am quite interested in the introspection work being done.
 > > I must admit that I do not have enough time to be directly involved or
 > > contribute ideas.  I would like to be more involved but I guess it is not to
 > > be.  At some point I will find the time to learn the new API and try to see
 > > how it fits with Java-GNOME.
 > 
 > What I hope we can do with the introspection work is turn the work
 > of writing a language binding from one of writing a large amount of
 > tedious code into one of writing a small amount of difficult code :-)
 > 
 > While the initial work may be harder, hopefully the job of continued
 > maintenance will be much less.
 
 Owen, I could not agree more with this goal.  
 
 > I don"t mean to pick on PangoLayout in particular, it just happened
 > to be the class I picked to review, since I have it more memorized
 > than much of the rest of GTK.
 > 
 > My point was mostly that with a manually maintained binding, you
 > have to become an expert in everybody"s favorite widget ... with
 > more automation, hopefully the PangoLayout binding can be right
 > with almost no specific work.
 
 The key to a successful bindings implementation based upon code 
 generation is to, as you stated above,  generate as much of the code 
 as possible (remove most if not all of the tedious work).  At the same
 time it is critical that the development team has the flexibility to shape
 the final public API.  For Java-GNOME this means that you would 
 definitely generate the JNI binding code and the Java native method 
 declarations (this is not that difficult).  Generation of the public API is
 a harder nut to crack.
 
 There are several approaches to consider for the public API generation:
 
 The peanut version - Do not generate any of the public API.  This allows
 the most flexibility for the API design but still has the developer performing
 a lot of tedious work and we are subject to inconsistencies (human error).
 For Java-GNOME the structure would look something like:
 
 Button.c   --> generated JNI layer
 GtkButton.java  --> generated native declarations for JNI layer
 Button.java  --> Hand coded public API that delegates all native calls to
     GtkButton.
 
 
 The cashew version - Generate all of the public API.  This provides less
 flexibility for the API design.  It does eliminate the need for all of the
 tedious work.  If done right developers could then take the resulting
 code and add additional methods to the classes to enhance the
 overall usability of the bindings.  For Java-GNOME the structure
 would look like:
 
 Button.c  --> generated JNI layer
 GtkButton.java  --> generated native declarations for JNI and generated
     public API.  This class would maintain the GObject hierarchy.
 Button.java  --> Class that inherits from GtkButton (thus exposing all of
     the generated public API) which can be used to add additional capabilities.
 
 It would also be possible to merge GtkButton and Button into a single class
 by having the generator merge generated and non-generated code.
 
 
 The walnut version - Generate the JNI code and Java native declarations.
 Also generate the public API using a style sheet concept for the code.
 The style sheet would include information such as whether a specific native
 method should generate a public API, is there any special handing for
 this method (should it be a constructor, etc.), what data types should be
 used for the parameters, javadoc comments, and anything else that is
 needed to define a robust API.  A global style sheet could be used to
 manage data type conversions.  Even this is not enough to eliminate
 the need for coding.  If the bindings wish to provide higher-level methods
 to simplify complex widgets (the tree control comes to mind) there
 has to be a place where hand written code can be inserted.  Maintaining
 the style sheet might be a pain in the <...>.  You could have the generator
 create the initial style sheet for you.  The generator could also perform a
 merge when the API for a widget changes.  In Java-GNOME the structure
 would be similar to the cashew version.
 
 
 There is another problem that exists.  Since we are part of the platform
 bindings we have to adhere to API stability rules.  It is likely that the
 generated code (if we generate to public API) will not exactly match
 our current API (we can only hope).  How can this be handled?
 
 
 Of course all of this depends upon the introspection work and our decision
 to move in this direction.  I know introspection is going to be included
 in gtk 2.8 but code generation is currently not even on our radar. I am 
 putting these ideas forward for discussion purposes only at this time.
 
 -Jeff

			

 Hey, thanks for the suggestions/problems pointed out.... now some comments:
 
 > Events
 > ======
 > [...]
 
 I"m glad you brought this up; a couple of months ago we actually had a
 quick discussion over this, and i think everybody kinda agreed that
 the best way would be to make Adapter classes
 (http://sourceforge.net/mailarchive/message.php?msg_id=10900057).
 
 We just haven"t had the time yet to sit and really *decide* what we"re
 going to do about it; maybe this is time now we should decide...
 
 > Memory Management
 > =================
 > [...]
 > One problem with memory management in gtk-java can be
 > expressed with a simple grep command:
 > Fixing this, within the constraints of the JNI is admittedly not
 > easy. In fact, I don"t know an entirely satisfactory way of doing so
 > without extending GObject. (I"m going to propose such an addition to
 > GObject for 2.8.) But you can do somewhat better. For example,
 > the approach that gtk# takes is to use strong reference from
 > the CLR object to the GObject and a weak reference in the
 > opposite direction.
 
 Hmmm... we should think of some way to address this issue. I think i
 didn"t understand very well what you said about what gtk# does; that
 is, what"s the weak reference in the opposite direction? I need to
 investigate this....
 
 > Completeness and Consistency of the Mapping
 > ===========================================
 > 
 > The Java-GNOME bindings seem largely done by hand. This approach
 > is going to cause problems with both completeness and with
 > consistency. A few examples:
 > [...]
 
 Awwww some "horrible" examples you picked there :P Ok, what you
 pointed out are definitely bugs which need to be fixed... i"m going to
 file a bug report on that.
 
 Jeff, i think we should write some guidelines/recommendations in the
 wiki about doing the bindings; you know, what method names to choose,
 etc.
 
 Cheers,
 J.V.

			

 
 
 
 On Tue, 2005-04-26 at 12:40 +0000, Joao Victor wrote:
 > Hey, thanks for the suggestions/problems pointed out.... now some comments:
 > 
 > > Events
 > > ======
 > > [...]
 > 
 > I"m glad you brought this up; a couple of months ago we actually had a
 > quick discussion over this, and i think everybody kinda agreed that
 > the best way would be to make Adapter classes
 > (http://sourceforge.net/mailarchive/message.php?msg_id=10900057).
 
 Something along those lines occurred to me, and having a 
 WidgetListener interface with all the different callbacks for
 Widget has a certain elegance, but there are some sticky 
 points as well:
 
 One problem I see is that you lose a lot of compile time
 safety ... 
 
  widget.addListener (new WidgetAdapter() {
    boolean destroy (Widget widget, event e) {
        return false;
     }
  } 
 
 Will compile correctly, but do nothing or throw an exception
 at runtime (should be destroyEvent). You haven"t gained very
 much over the addEventHandler() approach in terms of type safety.
 WidgetAdapter() above might as well be Object(). (*)
 
 On the GTK+ side, the problem with the code above is that Java-GNOME
 will have to connect to all 60+ signals on Widget to get one signal.
 This is horribly inefficient, and also can in some cases cause semantic
 changes (look at the input/output signals on GtkSpinButton.) Java-GNOME
 has this problem currently to some extent with things like
 ButtonListener.
 
 Maybe you could use introspection to figure out what methods
 of WidgetAdapter have been overridden and just connect those signals.
 Failing that, you"d need to do something like:
 
  widget.addDestroyEventListener (new WidgetAdapter() {
     boolean destroyEvent (Widget widget, event e) {
        return false;
     }
  } 
 
 Which isn"t too bad though it creates further problems not caught
 at compile-time.
 
 > > Memory Management
 > > =================
 > > [...]
 > > One problem with memory management in gtk-java can be
 > > expressed with a simple grep command:
 > > Fixing this, within the constraints of the JNI is admittedly not
 > > easy. In fact, I don"t know an entirely satisfactory way of doing so
 > > without extending GObject. (I"m going to propose such an addition to
 > > GObject for 2.8.) But you can do somewhat better. For example,
 > > the approach that gtk# takes is to use strong reference from
 > > the CLR object to the GObject and a weak reference in the
 > > opposite direction.
 > 
 > Hmmm... we should think of some way to address this issue. I think i
 > didn"t understand very well what you said about what gtk# does; that
 > is, what"s the weak reference in the opposite direction? I need to
 > investigate this....
 
 Currently, what Java-GNOME does is have a strong reference from GObject
 to Java object. Graphically:
 
              |
     Proxy  <---  GObject
              |
 
 As long as the GObject stays alive, the proxy stays alive. But the
 reverse is generally more important. If you only had the link in the
 opposite direction
 
              |
     Proxy   --->  GObject
              |
 
 It would work OK for things like PangoLayout, but other things become
 strange ... say you have a subclass of Window, MyWindow.
 
  mywindow.add(button);
  window2 = button.getParent();
 
 Then window2 is a Window not a  MyWindow. Creating both references
 strong causes memory leaks (see my toggle references mail). An
 almost-as-good approach is to use a weak reference in from the GObject
 to the Proxy object.
 
             |
    Proxy  <---  GObject 
            ...>
             |
 
 The "..." represents a weak reference. You could implement the weak
 reference with a JNI global weak reference (it would clear a pointer
 stored in the GObjects object data)  or out of the finalizer
 of the Proxy object. (it would clear an object data key)... either
 way the idea is that we can go back from GObject to Proxy object as
 long as the Proxy object is still kept alive from Java.
 
 The main problem with this is that if all Java references to the Proxy
 go away, then the Proxy is freed, and if recreated from the GObject , it
 will be a Window not a MyWindow and will have lost any data fields
 in the object.
 
 Regards,
 						Owen
 
 (*) You do gain a little bit ...I originally was going to mess up the
     return value instead of the function name, but it occurred to
     me that that would be caught since you can"t overload on return
     type.

			

 2005/4/25, Owen Taylor <otaylor@re...>:
 >  Window window = new Window (WindowType.TOPLEVEL);
 >  Button button = new Button ("Hello");
 >  window.add (button);
 >  window.remove (button);
 >  window.add (button);
 > 
 > Will segfault or at least produce warnings as the underlying
 > GtkObject is freed when the button is removed from the window
 > and the Java object is left holding an invalid pointer.
 
 If we "float" the object in the gtk.Button constructor, and unref it
 in the gtk.Button.finalize() method, would it solve this problem?
 
 Cheers,
 J.V.

			

 Quoting Joao Victor <jvital@gm...>:
 > If we "float" the object in the gtk.Button constructor, and unref it
 > in the gtk.Button.finalize() method, would it solve this problem?
 
 If by "float" you mean g_object_ref, then no. We would have a java reference
 from the gobject to the java object for the signal handler, so neither object
 would be freed.
 We must have a standard reference from gobject to java object to allow for
 anonymous classes as callbacks.
 
 --
    .""`. Mark Howard
   : :" :
   `. `"  http://www.tildemh.com
     `-   mh@de... | mh@ti...

			

 
 
 
 On Tue, 2005-04-26 at 13:33 +0000, Joao Victor wrote:
 > 2005/4/25, Owen Taylor <otaylor@re...>:
 > >  Window window = new Window (WindowType.TOPLEVEL);
 > >  Button button = new Button ("Hello");
 > >  window.add (button);
 > >  window.remove (button);
 > >  window.add (button);
 > > 
 > > Will segfault or at least produce warnings as the underlying
 > > GtkObject is freed when the button is removed from the window
 > > and the Java object is left holding an invalid pointer.
 > 
 > If we "float" the object in the gtk.Button constructor, and unref it
 > in the gtk.Button.finalize() method, would it solve this problem?
 
 I think you mean "sink". If you do that and leave the current JNI
 global reference, you"ll create a memory leak, because the GObject
 will reference the Java object and vice versa.
 
 So you need to *also* do something like make the reference from GObject
 to the Java object weak (see my last mail)
 
 Regards,
 					Owen

			

 
 
 
 [ This was held for moderation since I wasn't subscribed. Reposting,
   hopefully people won't get duplicate copies later ]
 
 I did some more fooling around today, and wanted to revisit an old
 discussion:
 
 On Mon, 2005-04-25 at 15:36 -0400, Owen Taylor wrote:
 
 > Events
 > ======
 > 
 > There are two problems with signal handling ... one problem is that it
 > is just clumsy:
 > 
 >   button.addListener (new ButtonListener () {
 >      public void buttonEvent (ButtonEvent event) {
 >          if (event.isOfType(ButtonEvent.Type.CLICK) {
 >            System.out.println("Button was clicked");
 >          }
 >      }
 >   });
 > 
 > In Python, say, this is:
 > 
 >  def onClick (button):
 >     print "Button was clicked";
 >  
 >  button.connect ("clicked", onClick);
 > 
 > Obviously, there is a syntax barrier for Java, but there is no real 
 > reason it couldn't be:
 > 
 >  button.connectClicked (new ButtonClickedListener () {
 >     public void run(Button button) {
 >       System.out.println("Button was clicked");
 >     }  
 >  }
 > 
 > Creating one helper class for each signal might be a bit
 > expensive... there are other cheaper mechanisms with less type
 > safety. [...]
 
 With some more thought I think it can be even nicer than the above:
 
  button.connect(new Button.Clicked() {
      public void clicked(Button button) {
          System.out.println("Button was clicked");
      }
  });
 
 Using a nested interface removes much of the clutter when browsing the
 class hierarchy and in import statements. Method overloading also helps.
 The signal name is reused for the callback method to for greater
 flexibility; a delegate can be used for multiple signals. (Maybe use
 'onClicked' rather than 'clicked' as the method name?)
 
 Is this approach expensive? Some quick testing indicates that the
 overhead for doing signals this way is about 350 bytes per signal
 definition (in the compressed jar file). Since there are < 250 public
 signals in GTK+, that's about 90k overall. I doubt other approaches are
 significantly cheaper.
 
 (I'm assuming an implementation done with GObject and Java
 introspection; if per-signal native marshalers are used, then the 
 code-size overhead is, of course, more.)
 
 So, to review:
 
  - Consistent and predictable mapping from GTK+ signals. (Noticed today
    that the basic ::destroy signal wasn't bound in libgtk-java,
    LifeCycleEvent.Type.DESTROY is actually ::destroy-event...)
 
  - Reasonably compact syntax
 
  - Allows more efficient implementation than the current system or
    adapter classes since we never have to connect to unnecessary 
    signals.
 
  - While the approach isn't AWT-like, or Swing-like, it seems OK on
    being Java-like. And will remove the announce of Eclipse quick-fix
    wanting to import java.awt.event.MouseListener rather than
    org.gnu.gtk.MouseListener :-)
 
 Regards,
 						Owen

			

 
 
 
 Hi, 
 
 On Wed, 2005-07-09 at 09:46 -0400, Owen Taylor wrote:
 <snip>
 >  - While the approach isn't AWT-like, or Swing-like, it seems OK on
 >    being Java-like. And will remove the announce of Eclipse quick-fix
 >    wanting to import java.awt.event.MouseListener rather than
 >    org.gnu.gtk.MouseListener :-)
 
 You can stop this from happening by adding an access rule to your
 project settings that forbids access to awt classes - this is what I did
 in the Java-GNOME plugin. You can do this as follows:
 
 Right click on the JRE System Library in your project -> Build Path ->
 Configure Build path ... -> Libraries tab -> expand the JRE System
 Library -> "Access rules" -> "Edit ..." -> "Add ..." -> select Forbidden
 in the "Resolution" combo and then add **/awt/** to the "Rule Pattern"
 
 I realize this isn't your main point, I just thought I'd let you know
 how to make your life a little easier with eclipse :)
 
 Cheers, Ben

			

 A long time ago, on Mon, 2005-05-09 at 14:44 -0400, Owen Taylor wrote:
 > I did some more fooling around today, and wanted to revisit an old
 > discussion: [signal handling]
 
 I've been saving this message for a long time, hoping I'd have a chance
 to address it. So it's been almost 6 months. Oh well. First I'll write
 my views on the subject, then inline reply to some of his comments.
 
 Owen's basic concern seems to be the verbosity and clumsiness of the
 Listener/Event pattern. When I first saw this pattern in java-gnome, I
 freaked, something along the lines of "Oh my lord, what the hell is
 this?" :)
 
 But my GUI programming in Java predates Java 1.1. When I learned AWT, it
 used a very basic event handling pattern. One of the reasons I never did
 port that code from Java 1.0.2 (we're talking 1998 here) was that I was
 completely mystified by the Listener/Event thing that the AWT in Java
 1.1 introduced.
 
 ... time ... passes ...
 
 As I understand it from Mark Howard and Jeff Morgan, they added the
 Listener/Event pattern for signal handling to Java because they felt it
 was the more familiar idiom for experienced Java programmer, especially
 those coming from Swing or AWT. 
 
 I believe that this was absolutely the correct decision to make. In
 fact, as I've looked around a bit (and over enterprise code that I've
 run (though didn't write - I'm an operations guy) I've realized just how
 prevalent this pattern is in the Java world. It's everywhere - EJB, JMS,
 all over the J2EE stack.
 
 And so, even though it's somewhat (ok, very) cumbersome **especially
 from the viewpoint of someone coming from the GTK C world**, it is
 natural indeed for someone coming from the Java world, and that
 (unscientifically) is the bulk of our userbase.
 
 ++
 
 Ok. So I've said that it's ok. But that doesn't mean it can't be
 improved - or ditched. To be honest, I'd like to see a better model.
 
 But switching will be tricky indeed. We already have 2 1/2 APIs for
 signal handling. [the Listener/Event pattern which most of us use, then
 the raw Event handling which happens to be exposed, and also method name
 hookups if you care to use Glade for that]
 
 When I was in Toronto last week I met with some of the guys (and Hiro,
 who came up from Waterloo!) and discussed this issue among others. The
 biggest problem I see is that we already are close to the boundary of
 having unmaintained/unsupported APIs, and if we don't do a clean break
 (not just deprecating but hard and fast REMOVING the old APIs in favour
 of the new one) then we will end up with an even worse situation.
 
 The only possible place for us to make such a break is at a major
 version number jump (ie libgtk-java moves from 2.x.y to 3.w.z) ... which
 is hard to do unilaterally as we are now somewhat historically tied to
 following the underlying GTK release numbers. [Note to self - moving
 from java-gnome 0.8.3 to java-gnome 2.4.x was probably a bad idea - we
 lost the freedom to make a major API change on our own schedule]. 
 
 To be honest, I don't much care about this - in the modern software
 world, 1.2 to 1.4 IS a major release. So if we need to change the signal
 handling we can probably do so whenever, but we should do so with lots
 of warning and RIP OUT whatever old models we're no longer going to
 support.
 
 ++
 
 Now on to specifics. If we do change (and incur all this administrative
 burden I've just been talking about, not to mention forcing a port of
 any and all applications), then we should make it a good one. There are
 all sorts of areas of the API that could do with improvement & redesign.
 
 In the case of signal handling, there seem to be two broad option paths,
 revolving around typing.
 
 The present system is strongly typed. We have KeyListeners and KeyEvents
 and TreeViewListeners and TreeViewEvents and also interfaces with
 similar APIs, eg   TreeModelFilterVisibleMethod. The advantage of this
 is that we allow ourselves to take advantage of the strengths of the
 Java language, getting appropriate methods for appropriate events, and
 having being able at compile time to catch wrong API mistakes.
 
 The other branch of options involve not using the type safety system at
 all, and doing all the lookups by strings. This is more "traditional"
 GTK, but also is less ideal programming practice because it means that
 you have to wait until runtime to find out if you misspelled a signal
 name. The usual result of such a bug is that simply nothing happens, but
 likewise situations where the wrong method gets called arise. Worst of
 all you loose any support that IDEs like Eclipse can give you both at
 code writing time and also at debugging time (call stacks become a
 mess). The upside is that the API is really simple, although not quite
 as simple as in C or Perl as one has to fight through a class / object
 somewhere to get to the method name you're trying to call.
 
 For me the promise of absolute simplicity is not worth the cost of not
 leveraging the strongly typed character of the language we're working
 in. But in the end, I'd make my vote on the basis of how elegant our
 proposed new system would be in use. 
 
 ++
 
 To close, some replies to Owen's comments: his first suggestion
 
 > >  button.connectClicked (new ButtonClickedListener () {
 > >     public void run(Button button) {
 > >       System.out.println("Button was clicked");
 > >     }  
 > >  }
 
 Isn't too bad. Strongly typed.
 
 > > Creating one helper class for each signal might be a bit
 > > expensive... 
 
 Expensive in authoring and a little less so in maintenance to be sure.
 But in runtime terms Java is already stacked full of objects. 20-300 for
 signals isn't going to hurt anything.
 
 Owen's second message notes that this is nicer:
 
 >  button.connect(new Button.Clicked() {
 >      public void clicked(Button button) {
 >          System.out.println("Button was clicked");
 >      }
 >  });
 
 and I agree, although in general I would note that even something as
 simple as Button has a plethora of signals that need implementing: from
 Button.Type I see ACTIVATE, CLICK, ENTER, LEAVE, PRESS, and RELEASE. For
 all I know there are more down in GTK that we haven't yet properly
 wrapped.
 
 > (Maybe use
 > 'onClicked' rather than 'clicked' as the method name?)
 
 [is click or clicked the underlying event-signal name?]
 
 Not sure. Java's APIs (and java-gnome's) are schitzo in this regard.
 You've got stuff like next() and item() and present() and activate()
 floating around, but then set*, get*, and is* prevails for all the
 property accessors and mutators. Perhaps on* as a family name isn't a
 bad idea.
 
 I have some thoughts on the API design sweepstakes, but this email is
 already too long as it is. I'll follow up if there is indeed interest in
 radically changing things. Otherwise, if we're just going to leave
 things be, then let's just keep things well maintained and work on
 fixing, if nothing else, the JavaDoc for all the bloody nested Type
 statics. I remember how hard it was to learn our event handling API,
 even with some examples to follow.
 
 AfC
 Bangalore

			

 On Wed, 2005-11-02 at 10:12 +0530, Andrew Cowie wrote:
 [...]
 > As I understand it from Mark Howard and Jeff Morgan, they added the
 > Listener/Event pattern for signal handling to Java because they felt it
 > was the more familiar idiom for experienced Java programmer, especially
 > those coming from Swing or AWT. 
 [...]
 
 I would like to mention that the Listener/Event pattern used in
 Java-Gnome isn't the same as the one used in Swing/AWT. It's more
 verbose and less safe. More verbose because it includes having to check
 the type of the Event, instead of just overriding the methods required.
 It is less safe because overloading is used for the addListener methods.
 In Java/Swing, those methods are called addActionListener,
 addWindowListener, etc. Using overloading where the number of parameters
 is the same and the objects can potentially be cast into each other is
 not recommended practice according to Joshua Bloch's Effective Java, for
 reasons that he explains in detail there.
 
 Regards,
 Ismael

			

 2005/11/2, Ismael Juma <ismael@ju...>:
 > On Wed, 2005-11-02 at 10:12 +0530, Andrew Cowie wrote:
 > I would like to mention that the Listener/Event pattern used in
 > Java-Gnome isn't the same as the one used in Swing/AWT. It's more
 > verbose and less safe. More verbose because it includes having to check
 > the type of the Event, instead of just overriding the methods required.
 > It is less safe because overloading is used for the addListener methods.
 > In Java/Swing, those methods are called addActionListener,
 > addWindowListener, etc.
 
 Yeah, that's what i was just going to write. I think we should try and
 change JG to do it the Java-way, or to some "similar" solution. An
 example of "similar" solution was given by Owen:
 
 --------
  button.connectClicked (new ButtonClickedListener () {
     public void run(Button button) {
        System.out.println("Button was clicked");
     }
 }
 --------
 
 In that example you have the safety, and it's not verbose. The downside is that:
 
 a) It's not 100% Java-like (which may look weird to newcomers)
 b) You'll tend to have many more (listener) objects instantiated,
 since you've got an object for every event.
 
 The upside is:
 a) If you like implementing listeners with annon classes, your code
 will probably be cleaner
 b) Sometimes different (from the Java-way) can be good/better =)
 
 BTW, maybe someone should CC/notify to Owen so he see the replies to
 his thread..
 
 Cheers,
 J.V.

			

 On Wed, 2005-02-11 at 12:25 -0200, Joao Victor wrote:
 > I think we should try and
 > change JG to ....
 
 [aside]
 
 Just keep in mind if we're going to change this at all, it's a MASSIVE
 change. I don't think that should stop us, but likewise I don't think we
 should be trying to maintain **or even expose** two different APIs so
 this will end up requiring any and every application (and example) to be
 ported to the new design.
 
 In Gentoo, I've got java-gnome slotted, so (for example) java-gnome
 series 2.12 and a hypothetical 3.0 can be installed simultaneously -
 thus apps written against libgtk-java 2.8 would still work after
 java-gnome 3.0 comes out. But the apps themselves will still have to be
 forward ported if the event handling model changes in a non API
 compatible way
 
 To re-iterate: I think we *should* redesign this API. In fact, let's
 figure out what else needs redesign and wedge it in at the same time.
 
 Incidentally, now is the time to plan something like this. And, I'd go
 so far as to suggest that if it takes 1.5 or 2 six month cycles, so be
 it. As I've mentioned before, if we need to skip an official gnome
 release date, no biggie. The question is whether we have the time and
 energy to do something of this magnitude in the next 4-10 months?
 
 Otherwise, even if the answer is "no, not right now", a worthy
 conversation. We can design the API and plan the changes, and then
 reconsider our window of opportunity as each 6 months passes.
 
 AfC
 Bangalore

			

 On Wed, 2005-11-02 at 21:49 +0530, Andrew Cowie wrote:
 [...]
 > Incidentally, now is the time to plan something like this. 
 [...]
 > The question is whether we have the time and
 > energy to do something of this magnitude in the next 4-10 months?
 [...]
 
 I think this is the key point. We must agree on a plan for the next
 releases. An IRC meeting would be helpful in this regard I think.
 
 Regards,
 Ismael

			

 2005/11/2, Ismael Juma <ismael@ju...>:
 > I think this is the key point. We must agree on a plan for the next
 > releases. An IRC meeting would be helpful in this regard I think.
 
 Yes, i agree with you both.
 
 But, i think, signals shouldn't be the focus of the next release,
 IMHO. I think the focus should be: getting things done more
 automatically. However, like you said, that doesn't mean we can't
 starting _planning_ it now.
 
 Cheers,
 J.V.

			

 
 
 
 On Wed, 2005-11-02 at 10:12 +0530, Andrew Cowie wrote:
 > A long time ago, on Mon, 2005-05-09 at 14:44 -0400, Owen Taylor wrote:
 > > I did some more fooling around today, and wanted to revisit an old
 > > discussion: [signal handling]
 > 
 > I've been saving this message for a long time, hoping I'd have a chance
 > to address it. So it's been almost 6 months. Oh well. First I'll write
 > my views on the subject, then inline reply to some of his comments.
 
 Thanks for the reply; my hope was mostly to get some ideas out in
 the air rather than looking for instant feedback.
 
 > Owen's basic concern seems to be the verbosity and clumsiness of the
 > Listener/Event pattern. When I first saw this pattern in java-gnome, I
 > freaked, something along the lines of "Oh my lord, what the hell is
 > this?" :)
 
 Well, I wouldn't characterize that as my core objection ... my core
 objection is really the lack of a consistent and predictable mapping
 between the GObject signature of an object and the Java signature.
 
 [...]
 
 > I believe that this was absolutely the correct decision to make. In
 > fact, as I've looked around a bit (and over enterprise code that I've
 > run (though didn't write - I'm an operations guy) I've realized just how
 > prevalent this pattern is in the Java world. It's everywhere - EJB, JMS,
 > all over the J2EE stack.
 > 
 > And so, even though it's somewhat (ok, very) cumbersome **especially
 > from the viewpoint of someone coming from the GTK C world**, it is
 > natural indeed for someone coming from the Java world, and that
 > (unscientifically) is the bulk of our userbase.
 
 The better the Java/GNOME bindings are,the more likely they
 are to attract people from the C world :-) Eclipse as a Java IDE
 far surpasses any other development environment out there for Linux
 for any language; that is (or should be) a pretty powerful attractive
 force.
 
 > To be honest, I don't much care about this - in the modern software
 > world, 1.2 to 1.4 IS a major release. So if we need to change the signal
 > handling we can probably do so whenever, but we should do so with lots
 > of warning and RIP OUT whatever old models we're no longer going to
 > support.
 
 I'd think incompatible changes are more constrained by messaging and 
 setting up to allow parallel installs of old and new versions (should
 be pretty easy for Java) than by version numbers. GTK+ 1.0 to 1.2 
 was an incompatible change, GTK+-2.x to 3.0, when/if that happens, may
 well *not* be an incompatible change.
 
 [...]
 
 > Owen's second message notes that this is nicer:
 > 
 > >  button.connect(new Button.Clicked() {
 > >      public void clicked(Button button) {
 > >          System.out.println("Button was clicked");
 > >      }
 > >  });
 > 
 > and I agree, although in general I would note that even something as
 > simple as Button has a plethora of signals that need implementing: from
 > Button.Type I see ACTIVATE, CLICK, ENTER, LEAVE, PRESS, and RELEASE. For
 > all I know there are more down in GTK that we haven't yet properly
 > wrapped.
 
 That's partly my concern about the non-automatable mapping :-), it's
 easy to miss stuff. From the stats in my last mail, there are about
 250 signals total in GTK+. That certainly encourages not doing them
 one-by-one by hand, and the use of nested interfaces to group them,
 but I don't think it's unmanageable.
 
 > > (Maybe use
 > > 'onClicked' rather than 'clicked' as the method name?)
 > 
 > [is click or clicked the underlying event-signal name?]
 
 It's 'clicked'; the general, though far from universal naming convention
 in GTK+ is that signals that are pure notification are in the past tense
 ('clicked', 'state-changed', while signals that expect an action from
 the handler are present tense 'popup-menu', 'show-help')
 
 > Not sure. Java's APIs (and java-gnome's) are schitzo in this regard.
 > You've got stuff like next() and item() and present() and activate()
 > floating around, but then set*, get*, and is* prevails for all the
 > property accessors and mutators. Perhaps on* as a family name isn't a
 > bad idea.
 
 I think the main reason to add the 'on' would be to support
 self-delegation:
 
  class MyButton extends Button implements Button.Clicked {
      MyButton() {
 	super("Hello World!");
 	connectClicked(this);
      }
 
      void onClicked() {
 	// do something 
      }
  }
   
 This doesn't work without the 'on' because Button has a clicked()
 method already. But you could achieve much the same thing with 
 one inner class. I think there are quite a few workable variants - 
 the main thing I'd push is "one listener interface per GObject 
 signal".
 
 Regards,
 						Owen