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

[Jeffrey M. <Jef...@Br...>]

Perhaps writing our own parser (very simple parser) is a 
good option.  My concern is not just with building the bindings
but also with distributing applications that use the bindings.
I am sure that many developers will want to use gcj to create
binaries.  Adding an additional external library will make
this more complicated.  There will be a need to compile the
xerces library into a shared object with gcj and distribute
it with their app.

Tom, how difficult do you think it will be to parse the xml
file without an xml parser?

-Jeff

> 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!! 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Get the new Palm Tungsten T 
> handheld. Power & Color in a compact size! 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
>