[java-gnome-hackers] LibGlade proposal

[Tom B. <Tom...@Su...>]

On Fri, 2002-10-18 at 03:57, Jeffrey Morgan wrote:
> I believe our libglade bindings need some help.  Since
> you have an interest in this I would appreciate it if you
> could take a look and make some recommendations.  One of
> the areas that I would like to see changed in the libglade 
> binding is the event handling.  As you can see from our 
> bindings we have just changed over to a more "java like" 
> event handling API.  libglade still wants to use the old 
> signal_connect method.  As a result I have had to keep our 
> old event handling structure public.

I've been doing some poking into java.gnu.glade.LibGlade, libglade-0.17,
and even other language bindings such as the ones for Python and Ruby
(glade-- for C++ seems focused on code generation rather than
dynamically loading the glade XML file at runtime).  For the most part,
these other bindings seem to be just glue to Glade's and GTK's C API. 
With all the work you've done to present a better event abstraction to
Java developers, I'd like the glade port to use it as well.

Here are the constraints as I understand them (please correct me where
I'm wrong, as these are used to evaluate possible solutions:

1.  The various events need to be mapped to the appropriate event class,
and then connected to a specified listener of that type.

No problem, LibGlade can do this by defining java.lang.reflect.Proxy
objects, similar to how the Java Beans persistence support is
implemented in 1.4.

2.  Although these listeners connect a typed event to a typed component,
they all need to be in the same class due to C naming conventions used
in the glade definition file.

Although this might make OO purists shudder, I think this approach is
more efficient than having a separate listener class for each widget
like the AWT does.  Conceptually, each "form" (as represented by a glade
XML file) has an associated event handling class.  By using Proxy
instances to connect event handlers to different widgets (instead of
defining separate anonymous inner classes as Swing and the AWT do), the
number of glue classes are cut to one.  Having all the event handlers in
one place also makes them easier to find.

3.  libglade separates widget instantiation from event handler
connection, and keeping those steps separate is wanted for Java-Gnome as
well.

It's faster to create the widget hierarchy and connect it at the same
time, but separating the two may be necessary for certain applications. 
I can't think of any, however, so if no one else can, maybe we should
keep it simple to begin with.

4.  It would be helpful if skeleton methods for the event handlers
needed by a glade definition file were generated.

Glade-- uses a command-line generator to create the files Glade creates
for C.  It would be easy to write an XML parser that generates a
LibGlade subclass with empty or "not implemented yet" method bodies for
each of the functions referenced in the glade file.

How does this sound?  Better ideas?  I'm open to just about anything...

Tom