RE: [java-gnome-hackers] First pass at libglade signal connecting

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

Wouldn't a URL link to it from our download and README be sufficient? 
It's fairly big (1.6M) and distributed with many other Java
distributions including many Java IDEs.  

I can also write a simple parser to eliminate the dependency, as all I
currently look for are the "signal" elements.  I was just trying to be
"politically correct" from an open source view.

Tom

On Mon, 2002-12-02 at 13:13, Jeffrey Morgan wrote:
> In your LibGladeStubs class you are using the xml libs.
> A question for the team is should we include the jars
> in our distribution?  This would reduce the number of
> additional downloads needed in order to build the bindings.
> 
> 
> 
> > I fixed the mapping layer, which had to map signal names and not 
> > listener method names.  Libglade should now basically work with GTK 
> > components.  Four pieces are not implemented yet: 
> Great.  I look forward to taking a look later today 8-) 
> 
> 
> > 1.  GNOME widget support, and I need a question answered:  the 
> > package-private EventMap class that was added to org.gnu.gtk either 
> > needs to be copied into org.gnu.gnome, or it needs to be 
> > moved somewhere 
> > common, such as org.gnu.glib.  The problem with making it 
> > common is that 
> > it has to then be public, and it's strictly an implementation 
> > class.  Is 
> > it sufficient to document that it's only to be used by this 
> > implementation?  I'd rather not duplicate code, but I also 
> > don't want an 
> > implementation class to become part of the official public API. 
> I think making it public in the glib package is the best approach. 
> I would not want to duplicate this in the gnome package either. 
> 
> 
> > 2.  Support for Glade's drop-down list of signal handlers, 
> > which allows 
> > a developer to map a signal directly to a GTK function, such 
> > as mapping 
> > a Window's destroy signal to gtk_main_quit().  I'm not sure how 
> > important this is since Python's libglade doesn't appear to support 
> > these handlers, but they aren't hard to add if you folks feel 
> > they'll be 
> > used. 
> I personally don't think these will be used.  I would like to 
> hear from the other developers on this one. 
> > 4.  Write tests and examples. 
> Good!!