java-gnome-hackers

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

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

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

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

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

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

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

[Sergio R. <ser...@hi...>]

Since in ppc and other archs there is no java 1.4.x and many people are
still working with 1.3.x I think it would be a good idea to include the
xerces parsers.

On Mon, 2002-12-02 at 22: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.
>=20
>=20
>=20
> > I fixed the mapping layer, which had to map signal names and not=20
> > listener method names.  Libglade should now basically work with GTK=20
> > components.  Four pieces are not implemented yet:=20
> Great.  I look forward to taking a look later today 8-)=20
>=20
>=20
> > 1.  GNOME widget support, and I need a question answered:  the=20
> > package-private EventMap class that was added to org.gnu.gtk either=20
> > needs to be copied into org.gnu.gnome, or it needs to be=20
> > moved somewhere=20
> > common, such as org.gnu.glib.  The problem with making it=20
> > common is that=20
> > it has to then be public, and it's strictly an implementation=20
> > class.  Is=20
> > it sufficient to document that it's only to be used by this=20
> > implementation?  I'd rather not duplicate code, but I also=20
> > don't want an=20
> > implementation class to become part of the official public API.=20
> I think making it public in the glib package is the best approach.=20
> I would not want to duplicate this in the gnome package either.=20
>=20
>=20
> > 2.  Support for Glade's drop-down list of signal handlers,=20
> > which allows=20
> > a developer to map a signal directly to a GTK function, such=20
> > as mapping=20
> > a Window's destroy signal to gtk_main_quit().  I'm not sure how=20
> > important this is since Python's libglade doesn't appear to support=20
> > these handlers, but they aren't hard to add if you folks feel=20
> > they'll be=20
> > used.=20
> I personally don't think these will be used.  I would like to=20
> hear from the other developers on this one.=20
> > 4.  Write tests and examples.=20
> Good!!=20
--=20
:: Rubio Jr. ::
ser...@hi...
http://rubiojr.dragon-lance.net

::  GrULLA   ::
http://grulla.hispalinux.es


" The number 1 tip for GTK+ programming is: =20

  - Don't use C; In my opinion, C is a library programming language
    not an app programming language. "
								=09
                                                  Owen Taylor.

 =20

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

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
> 

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

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

I understand and share your concerns.  Writing a simple parser won't be
hard, so I'll get right on it.

Tom

On Tue, 2002-12-03 at 04:50, Jeffrey Morgan wrote:
> 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
> >