java-gnome-hackers — Hacking on the bindings themselves: design issues and co-ordination

[java-gnome-hackers] Re: [Java-gnome-developer] Can't build from cvs

[Neven B. <nb...@en...>]

Thanks for your answer, I didn't realize I had to install ant for
java-gnome to build.
i installed it, and it seems to build ok, but when I try to make inst=
all
I get:

make: *** No rule to make target `gnome', needed by `install'.  Stop.

The last output form the make command is:

/usr/bin/ant -buildfile ../build.xml glade-jar
Buildfile: ../build.xml

build-glade:

glade-jar:

BUILD SUCCESSFUL
Total time: 6 seconds
make[1]: Leaving directory `/home/neven/download/java-gnome/src'
make -C test gnome glade
make[1]: Entering directory `/home/neven/download/java-gnome/test'
make[1]: Nothing to be done for `gnome'.
make[1]: Nothing to be done for `glade'.
make[1]: Leaving directory `/home/neven/download/java-gnome/test'

What might be te problem now?
Thanks again

--=20
Neven Boric <nb...@en...>

El lun, 16-12-2002 a las 15:01, Tom Ball escribi=C3=B3:=20
> Try running configure again -- it looks like src/Makefile wasn't cr=
eated
> correctly, as:
>=20
>     buildfile ../build.xml glade-jar
>=20
> should read:
>=20
>     $(ANT) -buildfile ../build.xml glade-jar
>=20
> Tom

[java-gnome-hackers] jndi-gconf

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

This weekend I'm going to work with two friends on a jndi implemetation
based on gconf. We are going to make the wrappers to the gconf library
and use them to implement the jndi specification. What do you think
about the idea? Do you have a piece of advice to share with me?

Cheers

Rubio Jr.

[java-gnome-hackers] Re: [Java-gnome-developer] Can't build from cvs

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

Try running configure again -- it looks like src/Makefile wasn't created
correctly, as:

    buildfile ../build.xml glade-jar

should read:

    $(ANT) -buildfile ../build.xml glade-jar

Tom

On Sat, 2002-12-14 at 11:22, Neven Boric wrote:
> Hi, I'm trying to build java-gnome from cvs and I'm getting the
> following  error:
> 
> gcc -g -O2 -fPIC -shared -o ../lib/libGladeJava.so.0.8.0 \
>         jni/org_gnu_glade_LibGlade.o \
>         -I/usr/include/libglade-2.0 -I/usr/include/gtk-2.0
> -I/usr/include/libxml2 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
> -I/usr/include/pango-1.0 -I/usr/include/Xft2 -I/usr/include/freetype2
> -I/usr/X11R6/include -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include   -lglade-2.0 -lgtk-x11-2.0 -lxml2 -lz
> -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0
> -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0   -I
> /usr/java/j2sdk1.4.1/include -I
> /usr/java/j2sdk1.4.1/include/linux \
>         -L../lib -lGTKJava  -Xlinker --no-undefined
> buildfile ../build.xml glade-jar
> make[1]: buildfile: Command not found
> make[1]: [glade] Error 127 (ignored)
> make[1]: Leaving directory `/home/neven/download/java-gnome/src'
> make -C test gtk glade
> make[1]: Entering directory `/home/neven/download/java-gnome/test'
> make[1]: Nothing to be done for `gtk'.
> make[1]: Nothing to be done for `glade'.
> make[1]: Leaving directory `/home/neven/download/java-gnome/test'
> 
> I'm using redhat 8.0 with all updates and java jdk 1.4.1
> 
> Thanks in advance
-- 
Tom Ball <Tom...@Su...>

Re: [java-gnome-hackers] status

[Mark H. <mh...@ti...>]

On Sat, 2002-12-14 at 03:20, Jeffrey Morgan wrote:
> > I've been trying the code over the last few days, but unfortunately have
> > failed on all occasions - On all events, I get exceptions called from
> > org.gnu.gdk.EventButton.getX(Native Method). Is this a known problem? is
> > it likely to be fixed in the next few days?
> 
> I am not seeing this problem.  Which example are you running when you
> get his exception?  I will look into it this weekend.

All of them I've tried recently...

I guess it must be something wrong with my environment then.

The screens render fine, but then whenever I click on a button I get
exceptions like the following:


An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x4C3F1F1E
Function=GdkEventButton_get_x+0x6
Library=/home/mark/java-gnome/lib/libGTKJava.so.0.8.0

Current Java thread:
	at org.gnu.gdk.EventButton.getX(Native Method)
	at org.gnu.gdk.EventButton.getX(EventButton.java:38)
	at org.gnu.gtk.event.MouseEvent.<init>(MouseEvent.java:98)
	at org.gnu.gtk.Widget.handleButtonPressed(Widget.java:866)
	at org.gnu.gtk.Gtk.gtk_main(Native Method)
	at org.gnu.gtk.Gtk.main(Gtk.java:54)
	at buttons.Buttons.main(Buttons.java:66)

Dynamic libraries:
08048000-0804d000 r-xp 00000000 03:05 35010     
/usr/lib/j2se/1.4/bin/java
0804d000-0804e000 rw-p 00004000 03:05 35010     
/usr/lib/j2se/1.4/bin/java
40000000-40011000 r-xp 00000000 03:04 110681     /lib/ld-2.3.1.so
40011000-40012000 rw-p 00011000 03:04 110681     /lib/ld-2.3.1.so
40012000-4001b000 r-xp 00000000 03:05 38158     
/usr/lib/j2se/1.4/jre/lib/i386/native_threads/libhpi.so
4001b000-4001c000 ---p 00009000 03:05 38158     
/usr/lib/j2se/1.4/jre/lib/i386/native_threads/libhpi.so
4001c000-4001d000 rw-p 00009000 03:05 38158     
/usr/lib/j2se/1.4/jre/lib/i386/native_threads/libhpi.so
4001d000-40020000 r--s 00000000 03:05 138473    
/usr/lib/j2se/1.4/jre/lib/ext/dnsns.jar
40020000-40023000 r-xp 00000000 03:05 24450     
/usr/lib/libgmodule-2.0.so.0.0.7
40023000-40024000 rw-p 00002000 03:05 24450     
/usr/lib/libgmodule-2.0.so.0.0.7
40026000-40033000 r-xp 00000000 03:04 110709     /lib/libpthread-0.10.so
40033000-40036000 rw-p 0000d000 03:04 110709     /lib/libpthread-0.10.so
40077000-40079000 r-xp 00000000 03:04 110694     /lib/libdl-2.3.1.so
40079000-4007a000 rw-p 00001000 03:04 110694     /lib/libdl-2.3.1.so
4007a000-40183000 r-xp 00000000 03:04 110692     /lib/libc-2.3.1.so
40183000-40189000 rw-p 00108000 03:04 110692     /lib/libc-2.3.1.so
4018d000-405f1000 r-xp 00000000 03:05 43942     
/usr/lib/j2se/1.4/jre/lib/i386/client/libjvm.so
405f1000-4060e000 rw-p 00463000 03:05 43942     
/usr/lib/j2se/1.4/jre/lib/i386/client/libjvm.so
4061e000-4062e000 r-xp 00000000 03:04 110696     /lib/libnsl-2.3.1.so
4062e000-4062f000 rw-p 00010000 03:04 110696     /lib/libnsl-2.3.1.so
40631000-40651000 r-xp 00000000 03:04 110695     /lib/libm-2.3.1.so
40651000-40652000 rw-p 0001f000 03:04 110695     /lib/libm-2.3.1.so
40652000-40661000 r-xp 00000000 03:05 43986     
/usr/lib/j2se/1.4/jre/lib/i386/libverify.so
40661000-40663000 rw-p 0000e000 03:05 43986     
/usr/lib/j2se/1.4/jre/lib/i386/libverify.so
40663000-40682000 r-xp 00000000 03:05 43993     
/usr/lib/j2se/1.4/jre/lib/i386/libjava.so
40682000-40684000 rw-p 0001e000 03:05 43993     
/usr/lib/j2se/1.4/jre/lib/i386/libjava.so
40684000-40699000 r-xp 00000000 03:05 125071    
/usr/lib/j2se/1.4/jre/lib/i386/libzip.so
40699000-4069c000 rw-p 00014000 03:05 125071    
/usr/lib/j2se/1.4/jre/lib/i386/libzip.so
4069c000-41d69000 r--s 00000000 03:05 216572    
/usr/lib/j2se/1.4/jre/lib/rt.jar
41dac000-41dc3000 r--s 00000000 03:05 138476    
/usr/lib/j2se/1.4/jre/lib/sunrsasign.jar
41dc3000-41e34000 r--s 00000000 03:05 138480    
/usr/lib/j2se/1.4/jre/lib/jsse.jar
41e34000-41e47000 r--s 00000000 03:05 138477    
/usr/lib/j2se/1.4/jre/lib/jce.jar
41e47000-42103000 r--s 00000000 03:05 216557    
/usr/lib/j2se/1.4/jre/lib/charsets.jar
441ab000-441af000 r-xp 00000000 03:05 83750     
/usr/X11R6/lib/libXrender.so.1.1
441af000-441b0000 rw-p 00003000 03:05 83750     
/usr/X11R6/lib/libXrender.so.1.1
4c230000-4c23e000 r--s 00000000 03:05 138475    
/usr/lib/j2se/1.4/jre/lib/ext/ldapsec.jar
4c23e000-4c240000 r-xp 00000000 03:05 83607     
/usr/X11R6/lib/X11/locale/common/xlcDef.so.2
4c240000-4c241000 rw-p 00001000 03:05 83607     
/usr/X11R6/lib/X11/locale/common/xlcDef.so.2
4c241000-4c243000 r-xp 00000000 03:05 82476     
/usr/lib/gconv/EUC-JP.so
4c243000-4c244000 rw-p 00002000 03:05 82476     
/usr/lib/gconv/EUC-JP.so
4c244000-4c24d000 r-xp 00000000 03:04 110697    
/lib/libnss_compat-2.3.1.so
4c24d000-4c24e000 rw-p 00009000 03:04 110697    
/lib/libnss_compat-2.3.1.so
4c24e000-4c26b000 r--s 00000000 03:05 138471    
/usr/lib/j2se/1.4/jre/lib/ext/sunjce_provider.jar
4c26b000-4c30a000 r--s 00000000 03:05 138474    
/usr/lib/j2se/1.4/jre/lib/ext/localedata.jar
4c30a000-4c379000 r--s 00000000 03:08 50205     
/home/mark/java-gnome/lib/gtk-0.8.0.jar
4c379000-4c390000 r--s 00000000 03:08 50774     
/home/mark/java-gnome/lib/gnome-0.8.0.jar
4c390000-4c398000 r--s 00000000 03:08 57912     
/home/mark/java-gnome/lib/glade-0.8.0.jar
4c398000-4c413000 r-xp 00000000 03:08 46058     
/home/mark/java-gnome/lib/libGTKJava.so.0.8.0
4c413000-4c416000 rw-p 0007a000 03:08 46058     
/home/mark/java-gnome/lib/libGTKJava.so.0.8.0
4c416000-4c60a000 r-xp 00000000 03:05 134102    
/usr/lib/libgtk-x11-2.0.so.0.0.9
4c60a000-4c615000 rw-p 001f4000 03:05 134102    
/usr/lib/libgtk-x11-2.0.so.0.0.9
4c617000-4c66a000 r-xp 00000000 03:05 134101    
/usr/lib/libgdk-x11-2.0.so.0.0.9
4c66a000-4c66f000 rw-p 00052000 03:05 134101    
/usr/lib/libgdk-x11-2.0.so.0.0.9
4c66f000-4c682000 r-xp 00000000 03:05 24638     
/usr/lib/libatk-1.0.so.0.0.3
4c682000-4c684000 rw-p 00013000 03:05 24638     
/usr/lib/libatk-1.0.so.0.0.3
4c684000-4c695000 r-xp 00000000 03:05 22066     
/usr/lib/libgdk_pixbuf-2.0.so.0.0.9
4c695000-4c696000 rw-p 00011000 03:05 22066     
/usr/lib/libgdk_pixbuf-2.0.so.0.0.9
4c696000-4c6b4000 r-xp 00000000 03:05 34079     
/usr/lib/libpangoxft-1.0.so.0.0.5
4c6b4000-4c6b5000 rw-p 0001d000 03:05 34079     
/usr/lib/libpangoxft-1.0.so.0.0.5
4c6b5000-4c6c0000 r-xp 00000000 03:05 34078     
/usr/lib/libpangox-1.0.so.0.0.5
4c6c0000-4c6c1000 rw-p 0000a000 03:05 34078     
/usr/lib/libpangox-1.0.so.0.0.5
4c6c1000-4c6e5000 r-xp 00000000 03:05 34077     
/usr/lib/libpango-1.0.so.0.0.5
4c6e5000-4c6f1000 rw-p 00023000 03:05 34077     
/usr/lib/libpango-1.0.so.0.0.5
4c6f1000-4c725000 r-xp 00000000 03:05 24449     
/usr/lib/libgobject-2.0.so.0.0.7
4c725000-4c727000 rw-p 00034000 03:05 24449     
/usr/lib/libgobject-2.0.so.0.0.7
4c727000-4c78a000 r-xp 00000000 03:05 3554      
/usr/lib/libglib-2.0.so.0.0.7
4c78a000-4c78b000 rw-p 00063000 03:05 3554      
/usr/lib/libglib-2.0.so.0.0.7
4c78b000-4c791000 r-xp 00000000 03:05 4723      
/usr/lib/gtk-2.0/2.0.0/engines/libcleanice.so
4c791000-4c792000 rw-p 00005000 03:05 4723      
/usr/lib/gtk-2.0/2.0.0/engines/libcleanice.so
4c792000-4c794000 r-xp 00000000 03:05 94754     
/usr/lib/gconv/ISO8859-1.so
4c794000-4c795000 rw-p 00001000 03:05 94754     
/usr/lib/gconv/ISO8859-1.so
4c79f000-4c7a6000 r-xp 00000000 03:05 83744     
/usr/X11R6/lib/libXi.so.6.0
4c7a6000-4c7a7000 rw-p 00006000 03:05 83744     
/usr/X11R6/lib/libXi.so.6.0
4c7a7000-4c7bc000 r-xp 00000000 03:05 83743     
/usr/X11R6/lib/libXft.so.1.1
4c7bc000-4c7be000 rw-p 00014000 03:05 83743     
/usr/X11R6/lib/libXft.so.1.1
4c7d0000-4c7dc000 r-xp 00000000 03:05 83742     
/usr/X11R6/lib/libXext.so.6.4
4c7dc000-4c7dd000 rw-p 0000c000 03:05 83742     
/usr/X11R6/lib/libXext.so.6.4
4c7dd000-4c894000 r-xp 00000000 03:05 83740     
/usr/X11R6/lib/libX11.so.6.2
4c894000-4c897000 rw-p 000b7000 03:05 83740     
/usr/X11R6/lib/libX11.so.6.2
4c897000-4c8e4000 r-xp 00000000 03:05 276038    
/usr/lib/libfreetype.so.6.3.2
4c8e4000-4c8e8000 rw-p 0004c000 03:05 276038    
/usr/lib/libfreetype.so.6.3.2
4c8e9000-4c8fc000 r-xp 00000000 03:05 34061     
/usr/lib/pango/1.0.0/modules/pango-basic-x.so
4c8fc000-4c8fd000 rw-p 00012000 03:05 34061     
/usr/lib/pango/1.0.0/modules/pango-basic-x.so
4c8fd000-4c915000 r-xp 00000000 03:05 150721    
/usr/lib/gconv/libJIS.so
4c915000-4c916000 rw-p 00017000 03:05 150721    
/usr/lib/gconv/libJIS.so
4c916000-4c976000 rw-s 00000000 00:05 635273255  /SYSV00000000 (deleted)

Local Time = Sun Dec 15 10:03:38 2002
Elapsed Time = 3
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (Blackdown-1.4.1-beta mixed mode)
#
# An error report file has been saved as hs_err_pid31816.log.
# Please refer to the file for further information.
#



-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

Re: [java-gnome-hackers] status

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

On Fri, 2002-12-13 at 07:37, Mark Howard wrote: 
> Hi all,
>   I'm back home from uni for Christmas, so have a little more time to
> work on Java-Gnome. Unfortunately, I've also got lots of other stuff to
> work on, so my time is very limited.

Welcome back.  

>   
>   What's the current status of the the project? I seem to remember
> someone saying that a 0.8.0 release might be possible by late November -
> how close are we to this? 

We have made much progress.  There is still plenty to do.  I would like
to release a build soon but we still have plenty of bugs.  

> I've been trying the code over the last few days, but unfortunately have
> failed on all occasions - On all events, I get exceptions called from
> org.gnu.gdk.EventButton.getX(Native Method). Is this a known problem? is
> it likely to be fixed in the next few days?

I am not seeing this problem.  Which example are you running when you
get his exception?  I will look into it this weekend.






-- 

Jeffrey Morgan <ku...@zo...>

[java-gnome-hackers] status

[Mark H. <mh...@ti...>]

Hi all,
  I'm back home from uni for Christmas, so have a little more time to
work on Java-Gnome. Unfortunately, I've also got lots of other stuff to
work on, so my time is very limited.
  
  What's the current status of the the project? I seem to remember
someone saying that a 0.8.0 release might be possible by late November -
how close are we to this? 
I've been trying the code over the last few days, but unfortunately have
failed on all occasions - On all events, I get exceptions called from
org.gnu.gdk.EventButton.getX(Native Method). Is this a known problem? is
it likely to be fixed in the next few days?

I would prefer to spend the next few weeks working on mostly bug hunting
and also developing some small apps which could be used as examples, but
would also be very useful programs (for me at least). If anyone has
anything specific they would like me to work on, please let me know.
I will also look into the pixmaps in trees problem.

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

[java-gnome-hackers] --with-gcj-compile works

[VEROK I. <vi...@in...>]

> Replaced java.lang.reflect.Proxy implementation with a delegate-based
> implementation.  This new implementation should work with gcj (not
> tested), be a bit faster and easier to maintain.

For the record: it does work with GCJ.  No GCJ-handpicked-from-CVS
necessary either.  Bug #648648 can be closed.

Most examples I compiled into native binaries work fine, although a couple
are consistently segfaulting on me (the color picker and font picker are
two notable ones).

Istvan

[java-gnome-hackers] --with-gcj-compile almost works now

[VEROK I. <vi...@in...>]

After ./configure --with-gcj-compile, the following patch
needs to be applied to the generated makefiles.  This compiles
the native libraries cleanly, and linking them to native
binaries is almost possible, too.  Error messages are listed
after the patch.


diff -urN java-gnome.orig/src/Makefile java-gnome/src/Makefile
--- java-gnome.orig/src/Makefile	2002-12-07 18:49:02.000000000 +0100
+++ java-gnome/src/Makefile	2002-12-07 18:21:35.000000000 +0100
@@ -119,7 +119,8 @@
 		sort | sed -e 's/\.c/\.o/g')
 
 GNOME_CLASSES:= \
-	$(shell ls java/org/gnu/gnome/*.java)
+	$(shell ls java/org/gnu/gnome/*.java) \
+	$(shell ls java/org/gnu/gnome/event/*.java)
 
 GNOME_O = ${GNOME_CLASSES:.class=.o}
 
@@ -143,12 +144,12 @@
 # native targets
 
 native-gtk:	$(GTK_O)
-	$(GCJ) -g -shared $(GTK_O) -o ../lib/libGTKJar.so.${version}
+	$(GCJ) -fPIC -fjni -g -shared $(GTK_O) -o ../lib/libGTKJar.so.${version}
 	@(cd ../lib; test ! -L libGTKJar.so && ln -s libGTKJar.so.${version} libGTKJar.so) || exit 0
 
 
 native-gnome:	native-gtk $(GNOME_O)
-	$(GCJ) -g -shared $(GNOME_O) -o ../lib/libGNOMEJar.so.${version}
+	$(GCJ) -fPIC -fjni -g -shared $(GNOME_O) -Ibuild-java/gtk -Ibuild-java/gnome -o ../lib/libGNOMEJar.so.${version}
 	@(cd ../lib; test ! -L libGNOMEJar.so && ln -s libGNOMEJar.so.${version} libGNOMEJar.so) || exit 0
 
 
@@ -180,7 +181,7 @@
 	@(cd ../lib; test ! -L libGladeJava.so && ln -s libGladeJava.so.${version} libGladeJava.so) || exit 0
 
 native-glade: $(GLADE_O)
-	$(GCJ) -g -shared $(GLADE_O) -o ../lib/libGladeJar.so.${version}
+	$(GCJ) -fPIC -fjni -g -shared $(GLADE_O) -Ibuild-java/gtk -I/opt/xalan/xalan.jar -o ../lib/libGladeJar.so.${version}
 	@(cd ../lib; test ! -L libGladeJar.so && ln -s libGladeJar.so.${version} libGladeJar.so) || exit 0
 
 
diff -urN java-gnome.orig/test/Makefile java-gnome/test/Makefile
--- java-gnome.orig/test/Makefile	2002-12-07 18:49:02.000000000 +0100
+++ java-gnome/test/Makefile	2002-12-07 17:32:33.000000000 +0100
@@ -37,9 +37,11 @@
 glade:
 
 native-gtk:	
-	
+
 native-gnome:
-	
+
+native-glade:
+
 # Targets to clean after us
 
 .PHONY: mostlyclean clean distclean maintainer-clean


The /opt/xalan/xalan.jar I used above is not a hard requirement,
anything will do that has the JAXP interface classes, such as the
xmlapis.jar archive distributed with Xerces.

Making a completely native binary out of the Glade example
Example1 results in just the following linking errors
(instead of the thousands that I received before):

../lib/libGTKJar.so: undefined reference to `java::lang::Throwable::getCause()'
../lib/libGTKJar.so: undefined reference to `java::lang::Throwable::initCause(java::lang::Throwable*)'
../lib/libGladeJar.so: undefined reference to `java::lang::reflect::Proxy::newProxyInstance(java::lang::ClassLoader*, JArray<java::lang::Class*>*, java::lang::reflect::InvocationHandler*)'
../lib/libGTKJar.so: undefined reference to `java::lang::Throwable::getStackTrace()'
../lib/libGTKJar.so: undefined reference to `java::lang::Throwable::setStackTrace(JArray<java::lang::StackTraceElement*>*)'
../lib/libGladeJar.so: undefined reference to `javax::xml::parsers::SAXParserFactory::newInstance()'
../lib/libGladeJar.so: undefined reference to `java::lang::reflect::InvocationHandler::class$'
collect2: ld returned 1 exit status

Since I just grabbed the libgcj-3.3.jar out of Debian's
current gcc-snapshot package, with no accompanying
native libraries, I suspect that these may also be
satisfied by a careful and complete upgrade to
gcc-snapshot.  I will look into it.

The current libgcj-3.3.jar appears to have support for
Throwable.initCause(), Throwable.setStackTrace(), and other
1.4 features, so those should not be a problem either.
And there was much rejoicing.

Istvan

Re: [Fwd: Re: [java-gnome-hackers] --with-gcj-compile]

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

I think it is essential that we support gcj.  I believe that the
classpath project (the class library used by gcj) will have a release
very shortly that will implement the majority of the 1.4 spec thanks
to a large number of patches from IBM.  I am not sure what version
of the jdk is currently supported by gcj but this should be our
minimum. 

On Wed, 2002-12-04 at 17:42, Tom Ball wrote:
> -----Forwarded Message-----
> 
> > From: VEROK Istvan <vi...@in...>
> > To: Tom Ball <Tom...@Su...>
> > Subject: Re: [java-gnome-hackers] --with-gcj-compile
> > Date: 04 Dec 2002 23:50:04 +0100
> > 
> > 
> > 
> > On Wed, 4 Dec 2002, Tom Ball wrote:
> > 
> > > I'm a big supporter of open software, but not obsolete software.  While
> > > gcj doesn't support Proxy (InvocationHandler is just an interface), it
> > > will have to soon or risk splitting the Java platform.  I suppose I
> > 
> > I just took a look at the GCC CVS, and they _do_ have
> > java.lang.reflect.Proxy support (whew!), it just doesn't yet seem to have
> > percolated down into the Debian packages I use, for some reason.
> > 
> > Istvan
> > 
> -- 
> Tom Ball <Tom...@Su...>
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Microsoft Visual Studio.NET 
> comprehensive development tool, built to increase your 
> productivity. Try a free online hosted session at:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> 

[Fwd: Re: [java-gnome-hackers] --with-gcj-compile]

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

-----Forwarded Message-----

> From: VEROK Istvan <vi...@in...>
> To: Tom Ball <Tom...@Su...>
> Subject: Re: [java-gnome-hackers] --with-gcj-compile
> Date: 04 Dec 2002 23:50:04 +0100
> 
> 
> 
> On Wed, 4 Dec 2002, Tom Ball wrote:
> 
> > I'm a big supporter of open software, but not obsolete software.  While
> > gcj doesn't support Proxy (InvocationHandler is just an interface), it
> > will have to soon or risk splitting the Java platform.  I suppose I
> 
> I just took a look at the GCC CVS, and they _do_ have
> java.lang.reflect.Proxy support (whew!), it just doesn't yet seem to have
> percolated down into the Debian packages I use, for some reason.
> 
> Istvan
> 
-- 
Tom Ball <Tom...@Su...>

[java-gnome-hackers] API proposal: remove GObject(int) and GObject.addEventHandler(*)

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

In the grand software tradition of "ready, fire, aim", I'd like to
remove some API calls that I just checked in lots of references to.  You
can see why I'm a big fan of refactoring!

Back when I first volunteered, Jeffrey said that he wanted to move
everything over to his new event handling architecture and away from the
use of GObject.addEventHandler().  With the EventMap code checked in,
the only remaining references outside of org.gnu.glib of addEventHandler
are in org.gnu.gnome, and I will eliminate them shortly.  Once that's
done, the addEventHandler methods can be made package-private to
org.gnu.glib.

I'd like to go a bit further and eliminate all the public constructors
that take an existing native handle (including the ones added to support
the above change).  These calls aren't typesafe, because they assume
that the caller knows the correct type of the handle, allowing for
strange and hard to debug errors later in the program's execution if the
GTK class doesn't match the Java-GNOME one.

What I'd like to use instead is a static factory method,
GObject.makeObject(int) (anyone have a better name?).  This method would
use gtk_type_name to get the actual class of the object, then create a
new Java-GNOME instance of that class and directly stuff the handle into
the object before returning it.  Client code that used to do this:

    Button btn = new Button(handle);

would be:

    Button btn = (Button)GObject.makeObject(handle);

In general, only Glade would actually do this.

org_gnu_glade_LibGlade.c has code to map the GTK class name to our own,
but that logic belongs somewhere like GObject since it can be broken if
we don't follow its hidden assumptions.  A simple GTK->Java-GNOME class
map would be much easier to maintain, and can aid documentation as well.

Comments?

Tom

[java-gnome-hackers] What's our minimum?

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

The message from Istvan regarding my use of Java API not supported by
gcj brings up a good meta-question:  what's the minimum Java API we
support?  If it's 1.2, then I need to replace my use of proxy classes
with something more awkward.  Whatever is decided, we should publicly
document it (and perhaps even build using it occasionally ;-).

Tom

Re: [java-gnome-hackers] --with-gcj-compile

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

Hi Istvan,

I'm not a team leader, but may be able to address some of these
problems.  You unfortunately grabbed a snapshot of our project when it
is in the midst of a massive API overhaul -- we hope to have things
cleaned up soon for a '0.8' release soon, but aren't there yet.  While
we appreciate all the feedback, you may want to join our "announce"
mailing list and wait until that event to minimize your frustration.

On Wed, 2002-12-04 at 09:55, VEROK Istvan wrote:
> The --extdirs is needed because I killed two birds with one stone:
> I have JDK 1.4.1 in /opt/jdk, and (on one hand) the Glade bindings
> want JAXP (understandable), and (on the other hand) the SignalHandler
> class wants to be a subclass of InvocationHandler, which is a Java
> 1.3 dependency (only satisfiable by /opt/jdk/jre/lib/rt.jar) introduced
> quite recently by Tom Ball.  No flames, just an honest question:
> was this really necessary?  I mean, from the free software angle.

I'm a big supporter of open software, but not obsolete software.  While
gcj doesn't support Proxy (InvocationHandler is just an interface), it
will have to soon or risk splitting the Java platform.  I suppose I
could write something similar, but it would be very difficult as there's
a lot of good work in the proxy support classes.

If you know of a cleaner way to dynamically tie a method to a widget
using the org.gnu.gtk.event Listener interfaces, I'd love to hear it. 
I'm not tied to using dynamic proxies; it's just that we're using them
for exactly what they were designed to do.  Being lazy (one attribute of
a good programmer), I would rather use what exists than recreate it.

BTW, I'm rewriting the glade file parser to not use JAXP or SAX, so our
stuff won't have as many external dependencies. 

> Then I discovered that I needed to edit build.xml's build-glade
> target to say

> <include name="org/gnu/glade/**"/>
>                             ^^^
> 
> because the resulting glade.jar contained practically nothing
> otherwise (I'm using Ant 1.5).  A recompile followed.

Already fixed and checked in; you unfortunately caught a one-day window
where that was broken.

> I have yet to get native compilation working.  I can get class files
> using Java-GNOME, but my efforts to compile, say,
> src/examples/glade/Examples1.java into a native binary have so
> far all failed with hundreds of linking errors like
> 
> ../lib/libGTKJar.so: undefined reference to 
> `org::gnu::gtk::SpinButton::gtk_spin_button_get_adjustment(int)'

It sounds like our Java classes can't access their associated native
methods when compiled natively.  That's either a bug in our build (most
likely) or a gcj bug.  Please file a bug so we'll fix this.  Right now,
my understanding is that native compilation is a lower priority than
just getting things working again after all the recent design changes.

Tom

[java-gnome-hackers] --with-gcj-compile

[VEROK I. <vi...@in...>]

Hi!

I'm new to Java-GNOME, but I've been reading the mailing list
web archives for the last four months or so.  I run Debian unstable,
with Sun's 1.4.1_01 JDK, and ran into a few snags when finally
getting around to trying to get Java-GNOME to work.  I'd like
to have your opinion on these.

First, I checked out the CVS repository, did

./configure --with-libdir=/home/vi/incoming/java-gnome/lib --with-gcj-compile

because I want to eventually be able to compile stuff to
native binaries (not just class files).
Next came a

make all

which failed with about 370 error messages about missing classes.
I found that these could be made to go away by amending
java-gnome/src/Makefile's native-gnome and native-glade targets
in the following way:

native-gnome:	native-gtk $(GNOME_O)
	$(GCJ) -g -shared $(GNOME_O) -Ibuild-java/gtk -Ibuild-java/gnome -o ../lib/libGNOMEJar.so.${version}
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

native-glade: $(GLADE_O)
	$(GCJ) -g -shared $(GLADE_O) -Ibuild-java/gtk --extdirs=/opt/jdk/jre/lib -o ../lib/libGladeJar.so.${version}
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The --extdirs is needed because I killed two birds with one stone:
I have JDK 1.4.1 in /opt/jdk, and (on one hand) the Glade bindings
want JAXP (understandable), and (on the other hand) the SignalHandler
class wants to be a subclass of InvocationHandler, which is a Java
1.3 dependency (only satisfiable by /opt/jdk/jre/lib/rt.jar) introduced
quite recently by Tom Ball.  No flames, just an honest question:
was this really necessary?  I mean, from the free software angle.

Anyway, back to my build process: I also added an empty native-glade
target to test/Makefile to quench another complaint about a missing
target.  Having built the thing at last,

make install

didn't seem to want to work at all.  Even the top Makefile's install
target is horribly broken (the Makefile.in's
"install: @INSTALL_TARGETS@_install" line will never result in the
correct value of "install: gtk_install gnome_install native_install").
Also, specifying "--with-libdir" above does not influence the
generated Makefile at all, so even if this target worked as advertised,
everything would still be installed under /usr/local, not where I
wanted.  So I gave up on "make install", and copied the generated
lib directory by hand.

Then I discovered that I needed to edit build.xml's build-glade
target to say

<include name="org/gnu/glade/**"/>
                            ^^^

because the resulting glade.jar contained practically nothing
otherwise (I'm using Ant 1.5).  A recompile followed.

I have yet to get native compilation working.  I can get class files
using Java-GNOME, but my efforts to compile, say,
src/examples/glade/Examples1.java into a native binary have so
far all failed with hundreds of linking errors like

../lib/libGTKJar.so: undefined reference to `org::gnu::gtk::SpinButton::gtk_spin_button_get_adjustment(int)'

My command line for this compilation was scrounged from
src/Makefile and said:

gcj -fPIC -fjni -g -O --classpath=/usr/share/java/libgcj.jar:${JG}/gtk.jar:${JG}/gnome.jar:${JG}/glade.jar:. Example1.java -o Example1 -L../lib -lGTKJar -lGNOMEJar -lGladeJar -lGTKJava -lGNOMEJava -lGladeJava

I get the exact same error messages if the last three -l*Java
library references are omitted.  Any ideas?

Cheers,
Istvan

P.S.: Please CC me, I'm not subscribed to the list.

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

Re: [java-gnome-hackers] warnings -> printStackTrace()

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

>   Is there any way to track when gtk/glib/... warnings are emitted
> (those ones seen in all most bug reports), so that we can then call (new
> Exception).printStackTrace() ?

Thanks for the prod -- I had a broken warning catcher, and your message
got me to fix it and check it in.  

There may be a better way to do this, but I define a log_handler method
which stores messages, then bound my native code with g_set_log_handler
and g_remove_log_handler calls.  I found that the first warning/error is
usually the important one, and so only store that one for my error
reporting.  Since I don't know how long-lived the message text is, I
strdup it and free the dupe after ThrowNew copies the message into the
exception.

Details are in the latest org_gnu_glade_LibGlade.c.

Tom

[java-gnome-hackers] warnings -> printStackTrace()

[Mark H. <mh...@ca...>]

Hi,
  Is there any way to track when gtk/glib/... warnings are emitted
(those ones seen in all most bug reports), so that we can then call (new
Exception).printStackTrace() ?


-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   mh...@de... | mh...@ti... | mh...@ca... 

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
> 

[java-gnome-hackers] sed problem in src/Makefile.in

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

The command "sed -e 's=\.c=\.o=g'" fails on Linux (and I suspect any
other Posix-compliant system).  Shouldn't the syntax be "sed -e
's/\.c/\.o/g'"?

Tom

[java-gnome-hackers] Vte checked in

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

Hi. I finally checked in the vte code. I've also checked a little build
script untill I have time to prepare the make and configure files.

TODO(by order of preference):

 - Check in an example.
 - Work on the event code.
 - Try to fix the makefile stuff.
 - Complete the binding and the documentation.
 - Write a short parragraph of how to use the widget.
 - Write tests?

Let me know what you think.



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

[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

[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] Libglade stubs file generator checked in

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

It might be very interesting to integrate this ability
into NetBeans and Eclipse.  This is long-term of course.

> > 3.  A Java implementation skeleton generator, which is a 
> utility that
> > reads a Glade definition file and generates a Java file 
> with stubs for
> > the referenced handlers.  
> 
> Done.  In src/bin is LibGladeStubs, which reads a Glade 2.0 
> XML file and
> creates a Java source file with stubs for the handler methods 
> specified
> in the glade file.  It also has a main so that once the stub 
> bodies are
> written the app can be run.
> 
> Tom
> 
> 
> 
> -------------------------------------------------------
> 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] Misc things

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

> I've the vte bindings ready to be commited. Although they need much 
> more work, they are fully usable now.

good work!

> Before I commit the code I want to modify the build.xml and the make 
> stuff so the bindings can be compiled correctly. I've already added 
> things to the build.xml to compile the vte java classes. The new 
> targets are build-vte and vte-jar. I also fixed some build.xml bugs 
> which prevented ant from behaving properly. The java code was always 
> compiled because ant searched the compiled classes in the wrong 
> directory. The java classes were up to date, but ant compiled 
> again al 
> the code because it couldn't find the already compiled ones.

thanks.

> I'm now trying to fix the configure and make stuff, getting 
> it ready to 
> compile the vte part, but It's difficult for me. What do you think 
> about making the build process for the native things independent from 
> the java sources build process ? I mean, using make to build with gcc 
> and after that, calling ant manually to build the java code. 
> IMHO this 
> would make the scripts easier and smaller and we could use the ant 
> properties in the command line to switch between jikes, modern or gcj.
> 
> I need a piece of advice.

I personally would like to keep the two together if it isn't too much
work.  Most people in the open source world are use to the 
configure; make; make install approach to development.  What type of
problems are you running into?

-Jeff