From: Owen Taylor <otaylor@re...> Some notes on Java-GNOME 2005-04-25 12:30

     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 ]

From: Jeff Morgan <kuzman@gm...> Re: Some notes on Java-GNOME 2005-04-25 18:42

     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

From: Owen Taylor <otaylor@re...> Re: Some notes on Java-GNOME 2005-04-26 07:32

     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

From: Jeff Morgan <kuzman@gm...> Re: Some notes on Java-GNOME 2005-04-26 13:30

     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

From: Joao Victor <jvital@gm...> Re: Some notes on Java-GNOME 2005-04-26 05:40

     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.

From: Owen Taylor <otaylor@re...> Re: Some notes on Java-GNOME 2005-04-26 06:44

     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.

From: Joao Victor <jvital@gm...> Re: Some notes on Java-GNOME 2005-04-26 06:33

     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.

From: Mark Howard <mh@ti...> Re: Some notes on Java-GNOME 2005-04-26 06:57

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

From: Owen Taylor <otaylor@re...> Re: Some notes on Java-GNOME 2005-04-26 07:00

     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

From: Owen Taylor <otaylor@re...> Signals redux [was Re: Some notes on Java-GNOME] 2005-09-07 06:46

     [ 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

From: Ben Konrath <ben@ba...> Re: Signals redux [was Re: Some notes on Java-GNOME] 2005-09-26 18:06

     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

From: Andrew Cowie <andrew@op...> Re: Signals redux 2005-11-01 22:11

     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

From: Ismael Juma <ismael@ju...> Re: Signals redux 2005-11-02 00:57

     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

From: Joao Victor <jvital@gm...> Re: Signals redux 2005-11-02 06:26

     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.

From: Andrew Cowie <andrew@op...> Re: Signals redux 2005-11-02 08:19

     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

From: Ismael Juma <ismael@ju...> Re: Signals redux 2005-11-02 08:48

     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

From: Joao Victor <jvital@gm...> Re: Signals redux 2005-11-05 03:55

     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.

From: Owen Taylor <otaylor@re...> Re: Signals redux 2005-11-05 07:27

     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