Re: [java-gnome-hackers] LibGlade proposal

[Jeffrey M. <ku...@zo...>]

On Sun, 2002-10-27 at 20:31, Tom Ball wrote:
> 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...
> 

This is exactly what I had in mind.  My vote is to move forward
with the proposal.

-Jeff