java-gnome-developer — For people using the bindings to write their own applications

Re: [Java-gnome-developer] errors

[Damien C. <da...@co...>]

I've included my classpath and details of how I am compiling/running.  
Hope you can help.



Alex Moreno wrote:

>It seems that your classpath is not correct. You should make
>CLASSPATH='/usr/java/j2sdk1.4.2_02/jre/lib/ext'. And with an only 'java
>First' it shoul work. The '-cp .' argument is not necessary because java
>includes the working directory by default.
>
>Try to fix it or send us your 'echo $CLASSPATH' to let us help you.
>
[damien@localhost GnomeApp]$ echo $CLASSPATH
/usr/share/java-1.4.2:/usr/share/java-gnome:/usr/share/java-1.3.1:/usr/java/j2sdk1.4.2_02/jre/lib/ext/:/usr/java/j2sdk1.4.2_02/jre/lib/ext/:.
[damien@localhost GnomeApp]$ javac First.java
[damien@localhost GnomeApp]$ java First
Exception in thread "main" java.lang.UnsatisfiedLinkError: no GTKJava in 
java.library.path
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1491)
        at java.lang.Runtime.loadLibrary0(Runtime.java:788)
        at java.lang.System.loadLibrary(System.java:834)
        at org.gnu.glib.GObject.<clinit>(GObject.java:154)
        at First.main(First.java:10)

>
>On Tue, 2003-12-16 at 10:22, Damien Covey wrote:
>  
>
>>Hi,
>>
>>I'm new to Java-gnome and I am trying to get up and running.
>>
>>I'm attempting to run the simplest of programs from the Java-gnome
>>tutorial :
>>
>>    
>>
>>>// First we import the libraries used by this example
>>>import org.gnu.gnome.App;
>>>import org.gnu.gnome.Program;
>>>import org.gnu.gtk.Gtk;
>>>
>>>public class First {
>>>
>>>  public static void main(String[] args) {
>>>    // Initialization
>>>    Program.initGnomeUI("First", "0.1", args);
>>>
>>>    App app = new App("First", "First App");
>>>    app.show();
>>>
>>>    Gtk.main();
>>>  }
>>>}
>>>      
>>>
>>I can compile this easy enough with javac First.java.
>>However when I try to run java -cp . First is get:
>>
>>    
>>
>>>[damien@localhost GnomeApp]$ java -cp . First
>>>Exception in thread "main" java.lang.UnsatisfiedLinkError: no
>>>GTKJava in java.library.path
>>>        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1491)
>>>        at java.lang.Runtime.loadLibrary0(Runtime.java:788)
>>>        at java.lang.System.loadLibrary(System.java:834)
>>>        at org.gnu.glib.GObject.<clinit>(GObject.java:154)
>>>        at First.main(First.java:10)
>>>[damien@localhost GnomeApp]$
>>>      
>>>
>>Does anyone have any ideas about how to fix this?
>>I have build java-gnome and places all the .jar 's in
>>/usr/java/j2sdk1.4.2_02/jre/lib/ext.
>>
>>Regards
>>
>>-- 
>>Damien Covey
>>    
>>


-- 
Damien Covey
www.covey.net.au

[Java-gnome-developer] strange problem with the list

[Alex M. <ale...@gl...>]

It´s really strange. I can send messages to the list with an
external server located in fastmail.fm but, when i try to use my own
qmail server, it simply seems that no emails arrive to sourceforge. The
server is ok, other lists and people receive my messages... Maybe some
filtering opctions in spam assassing are blocking my emails? Can someone
help me or say what can i do?

Thanks
-- 
  Alex Moreno

[Java-gnome-developer] errors

[Damien C. <da...@co...>]

Hi,

I'm new to Java-gnome and I am trying to get up and running.

I'm attempting to run the simplest of programs from the Java-gnome 
tutorial :

> // First we import the libraries used by this example
> import org.gnu.gnome.App;
> import org.gnu.gnome.Program;
> import org.gnu.gtk.Gtk;
>
> public class First {
>
>   public static void main(String[] args) {
>     // Initialization
>     Program.initGnomeUI("First", "0.1", args);
>
>     App app = new App("First", "First App");
>     app.show();
>
>     Gtk.main();
>   }
> }

I can compile this easy enough with javac First.java.
However when I try to run java -cp . First is get:

> [damien@localhost GnomeApp]$ java -cp . First
> Exception in thread "main" java.lang.UnsatisfiedLinkError: no GTKJava 
> in java.library.path
>         at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1491)
>         at java.lang.Runtime.loadLibrary0(Runtime.java:788)
>         at java.lang.System.loadLibrary(System.java:834)
>         at org.gnu.glib.GObject.<clinit>(GObject.java:154)
>         at First.main(First.java:10)
> [damien@localhost GnomeApp]$


Does anyone have any ideas about how to fix this?
I have build java-gnome and places all the .jar 's in 
/usr/java/j2sdk1.4.2_02/jre/lib/ext.

Regards

-- 
Damien Covey <www.covey.net.au>

Re: [Java-gnome-developer] CVS changes

[Mark W. <ma...@kl...>]

Hi,

On Sat, 2003-12-13 at 19:35, Mark Howard wrote:
> Until they fix this, I have uploaded a tarball to:
> http://java-gnome.sourceforge.net/tmp/java-gnome-20031213-1823.tar.bz2

Quickly tried this out. And it seems to compile on my Debian unstable
installation with --with-kaffe and with a symlink in /usr/share/java of
libgcj-3.3.3.jar -> libgcj.jar. Also the javac (kjc) included with kaffe
doesn't have a -sourcepath option, but having a javac -> jikes-classpath
solved that problem.

Also (although this wasn't a real problem) newer versions of kaffe don't
have a Klasses.jar anymore. They do have a jre/lib/rt.jar though.

Thomas Fitzsimmons, a gcj hacker, noticed that you need at least
autoconf 2.58 since 2.57 gave some strange errors. He recommended adding
AC_PREREQ(2.58).

make install seems broken since INSTALL isn't defined in the Makefiles.

The java source code still seems to load GTKJava and GNOMEJava. Is this
still correct now that the library is split into smaller chunks?

But I didn't really got it working. Looking at the build log, I saw a
couple of errors and warnings that look suspicious.

There are a couple of errors when building glade:

        /tmp/java-gnome-20031213-1823/java-gnome/javac -sourcepath java -d =
build-java \
                java/org/gnu/glade/AdjustmentDelegate.java
        =20
        Found 60 semantic errors compiling "java/org/gnu/glade/ListenerDele=
gate.java":
        =20
            22. import org.gnu.gnome.event.AppBarListener;
                       ^--------------------------------^
       =20
Seems like a class/sourcepath setting error.

Also there are a lot of warnings when linking gtkhtml like:

        gcc -g -O2 -fPIC -shared -o ../lib/libgtkhtmljava0.8.so.0.8.2 \
                jni/org_gnu_gtk_html_HTMLContext.o jni/org_gnu_gtk_html_HTM=
LDocument.o jni/org_gnu_gtk_html_HTMLParser.o jni/org_gnu_gtk_html_HTMLView=
.o jni/org_gnu_gtk_html_dom_DomNode.o \
                -g -O2 -fPIC  -I /usr/local/kaffe/include/kaffe -Xlinker --=
no-undefined
        jni/org_gnu_gtk_html_HTMLContext.o(.text+0x15): In function `Java_o=
rg_gnu_gtk_html_HTMLContext_gtk_1html_1context_1get_1type':
        jni/org_gnu_gtk_html_HTMLContext.c:36: warning: undefined reference=
 to `gtk_html_context_get_type'
        jni/org_gnu_gtk_html_HTMLContext.o(.text+0x35): In function `Java_o=
rg_gnu_gtk_html_HTMLContext_gtk_1html_1context_1get':
        jni/org_gnu_gtk_html_HTMLContext.c:47: warning: undefined reference=
 to `gtk_html_context_get'
       =20
vte-Terminal doesn't compile:

        gcc -c -g -O2 -fPIC jni/org_gnu_gnome_vte_Terminal.c -o jni/org_gnu=
_gnome_vte_Terminal.o -I /usr/local/kaffe/include/kaffe -I/usr/include/gtk-=
2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-=
1.0 -I/usr/include/freetype2 -I/usr/X11R6/include -I/usr/include/glib-2.0 -=
I/usr/lib/glib-2.0/include  \
            -I/usr/include/gtkhtml-2.0 -I/usr/include/gtk-2.0 -I/usr/includ=
e/libxml2 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/=
pango-1.0 -I/usr/include/freetype2 -I/usr/X11R6/include -I/usr/include/glib=
-2.0 -I/usr/lib/glib-2.0/include   -DORBIT2=3D1 -pthread -I/usr/include/lib=
gnomeui-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 -=
I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/u=
sr/include/libbonoboui-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/incl=
ude -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gn=
ome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activati=
on-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0=
/include -I/usr/include/atk-1.0 -I/usr/X11R6/include -I/usr/include/libxml2=
   -I/usr/include/libglade-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libxml=
2 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.=
0 -I/usr/include/freetype2 -I/usr/X11R6/include -I/usr/include/glib-2.0 -I/=
usr/lib/glib-2.0/include
        jni/org_gnu_gnome_vte_Terminal.c:25:21: vte/vte.h: No such file or =
directory
        jni/org_gnu_gnome_vte_Terminal.c: In function `Java_org_gnu_gnome_v=
te_Terminal_vte_1terminal_1fork_1command':
        jni/org_gnu_gnome_vte_Terminal.c:56: error: `gchar' undeclared (fir=
st use in this function)

Let me know if there is anything I should try to help you get this release =
rolling.

Cheers,

Mark

Re: [Java-gnome-developer] Apps (was: CVS changes)

[Luca De R. <pie...@li...>]

Il gio, 2003-12-11 alle 20:14, Mark Howard ha scritto:
> I removed gnome-postal and cromagnon from cvs -- it is time for them to
> move to another project. 
I agree, I could get CroMagnon into a new Sf project, but I don't aobut
gnome-postal: TBH hacking on cromagnon is nice and, although in practice
I make a little use of it, it could grow with new feature and AFAIK
there aren't other gtk crontab guis around. But for a mail client we
have a such large app like evolution and many other nuce apps like
sylpheed, balsa, kmail so I don't have so much intererst in it...

I'm sorry to say that I have to wait next year to do some real work on
cromagnon and gnome-java (new hardware, finished exams...), however I'll
try to do what I'm able to.

If everyone agree I'm going to open a new project for cromagnon, maybe
after working on the api changes list which at the moment it's more
important. 

-- 
Luca De Rugeriis <pie...@li...>

Re: [Java-gnome-developer] GTK Changes

[Luca De R. <pie...@li...>]

Il gio, 2003-12-11 alle 13:29, Mark Howard ha scritto:
> We need to have a similar list created for libgnome, libgnomeui and
> libglade (as a minimum). 
I' ll do it, but I think there is really no time to file single bug
reports.

-- 
Luca De Rugeriis <pie...@li...>

Re: [Java-gnome-developer] (no subject)

[Luca De R. <pie...@li...>]

Hi all,
I' m sorry I haven't partecipated these days: unfortunately I have no
more access to a decent pc, I'm stuck with a P 200Mhz :((
I could use my girlfriend's one, but not everytime I'll need it.
This is bad cause it takes me a life to compile, so I think I couldn't
try the new build before Monday.
Also I'm on exam (guess what? uml & java, quite hard stuff for me).

Il mer, 2003-12-10 alle 14:41, Mark Howard ha scritto:
> cvs hacking - Let me know if it's ok & I'll get to it.
Ok. Modularity is good.

> tarballs - we'll release more of these after the cvs hackery
Ok: I think that an all-in-one tarball is vital: modularity is fine,
however the whole gnome is experiencing the difficulty to build gnome
itself, so garnome, etc... rised up. I've read in the past (on a
gnome-developer list) that they thought gnome was falling behind kde
also because building gnome is hard (at least it's impractical), and
because the haven't a way to distribute it quickly, like an all-in-one
tarball :)

> focus - work more on existing bindings while there are pending bug
>    reports, then look to new libraries
Agreed.

> version numbering - let me know if you disagree my proposal above
Ok. Have separate stable/unstable branches it's a benefit for users and
above all for us :)

> sourceforge - anyone second my proposal
Gnome.org
+ they have bugzilla.
+ we hope they update things faster (sf web interface is never updated).
+ it feels like it's a better place for java-gnome.(more official)
- I don't know how the do cvs acces and stuff like this and if they have
docs. But I think this isn't a problem at all.

Sf.net
+ Very popular repo.
+ They have a lot of services( compile farm etc..)
- There services aren't always reliable.

I think we should move to benefit from the use of e.g bugzilla, but
leave a sf project entry and maybe upload the tarballs there too.

-- 
Luca De Rugeriis <pie...@li...>

Re: [Java-gnome-developer] CVS changes

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

On Sat, Dec 13, 2003 at 09:20:22AM -0500, Jeffrey Morgan wrote:
> At this time I am not sure anybody but you can access
> the repository.  I have tried everything I can think
> of and am unable to get the source.  We must get this
> fixed as soon as possible.
I'm not certain what's wrong with this. The #cvs.lock file is not in the
tarball I uploaded to sourceforge. I think the CVS/Entry error you
are getting is because you tried to fetch java-gnome, which failed then
you only get the CVS/Entry error when you try again - CVS/Entry is not a
file in the cvs repository, it is only created for your local sandbox.

The web interface to cvs is working, which is very strange. 

I think the most likely cause of the problem is incorrect permissions on
some of the files in the repository. I will open a support request on
sourceforge, but it's unlikely that they will look at it until Monday.

Until they fix this, I have uploaded a tarball to:
http://java-gnome.sourceforge.net/tmp/java-gnome-20031213-1823.tar.bz2

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

Re: [Java-gnome-developer] CVS changes

[Luca De R. <pie...@li...>]

Il sab, 2003-12-13 alle 12:30, Jeffrey Morgan ha scritto:
> I am not able to checkout any code from the repository.  Can
> anybody else get the code?
Same problem...

> cvs checkout: ignoring java-gnome (CVS/Entries missing)
> cvs checkout: in directory java-gnome:
> cvs checkout: cannot open CVS/Entries for reading: No such file or
> directory
It seems it's missing the CVS/Entry dir.

-- 
Luca De Rugeriis <pie...@li...>

Re: [Java-gnome-developer] CVS changes

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

At this time I am not sure anybody but you can access
the repository.  I have tried everything I can think
of and am unable to get the source.  We must get this
fixed as soon as possible.

-Jeff

On Sat, 2003-12-13 at 08:04, Mark Howard wrote:
> On Fri, Dec 12, 2003 at 08:26:32PM +0000, Mark Howard wrote:
> > I'm going to stop my development now since things are working slightly.
> I couldn't just leave it in such a bad state, so I started reading make
> docs this morning and made more modifications. I'm uploading my changes
> now.
> 
> The make scripts should now work much better. They also (correctly) only
> build what actually needs to be build - an improvement on the previous
> make scripts. We also no longer depend on ant. 
> 
> There are a few items on the build TODO though:
>  - make gcj native builds optional -- at the moment, they are always
>    built.
>  - improve makefiles for the documentation packages
>  - improve location detection of gtk jar file (for e.g. gnome tarball)
>  - TEST
> 
> Please test this now if you can. I will release 0.8.2 tarballs based on
> this tomorrow so that people who don't like cvs can start testing -- we
> need to make sure this works well before the release to send to gnome (8
> days)
> 
> If you do test it, please send a report here - even if it worked
> perfectly. Please send details of *any* errors you see.

Re: [Java-gnome-developer] CVS changes

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

On Fri, Dec 12, 2003 at 08:26:32PM +0000, Mark Howard wrote:
> I'm going to stop my development now since things are working slightly.
I couldn't just leave it in such a bad state, so I started reading make
docs this morning and made more modifications. I'm uploading my changes
now.

The make scripts should now work much better. They also (correctly) only
build what actually needs to be build - an improvement on the previous
make scripts. We also no longer depend on ant. 

There are a few items on the build TODO though:
 - make gcj native builds optional -- at the moment, they are always
   built.
 - improve makefiles for the documentation packages
 - improve location detection of gtk jar file (for e.g. gnome tarball)
 - TEST

Please test this now if you can. I will release 0.8.2 tarballs based on
this tomorrow so that people who don't like cvs can start testing -- we
need to make sure this works well before the release to send to gnome (8
days)

If you do test it, please send a report here - even if it worked
perfectly. Please send details of *any* errors you see.

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

Re: [Java-gnome-developer] CVS changes

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

I am not able to checkout any code from the repository.  Can
anybody else get the code?

cvs checkout: ignoring java-gnome (CVS/Entries missing)
cvs checkout: in directory java-gnome:
cvs checkout: cannot open CVS/Entries for reading: No such file or
directory
cvs server: Updating java-gnome
cvs server: failed to create lock directory for
`/cvsroot/java-gnome/java-gnome'
(/cvsroot/java-gnome/java-gnome/#cvs.lock): Permission denied
cvs server: failed to obtain dir lock in repository
`/cvsroot/java-gnome/java-gnome'
cvs [server aborted]: read lock failed - giving up


-Jeff

On Fri, 2003-12-12 at 15:26, Mark Howard wrote:
> This is proving to be a lot trickier than I anticipated. I now have the
> makefiles in java-gnome/gtk working, building a library including
> glib,gdk,gtk,pango and atk (they have to be put together due to circular
> dependencies). gnome,gtkhtml and glade are also working, apart from the
> gcj native builds.
> 
> I'm going to stop my development now since things are working slightly.
> The make scripts still need a lot of work doing to them before the
> release (10 days max!). If anybody on this list knows even the slightest
> about make, please could you fetch java-gnome from cvs and try building
> it.
> 
> 
> TODO: (please help)
>   - find out why @GCJFLAGS@ isn't working
>   - get gcj native builds working
>   - get separate tarball builds working. (All my work so far has been
> 	trying to get the main cvs tree/all-in-one tarball to build). This
> 	involved writing configure scripts for each module which will find
> 	the required libraries, e.g. the gnome config script will replace
> 	@GTKJAR@ with the path to the gtk jar file, @NATIVEGTKJAR@ with the
> 	path to the so file, etc.
>   - makefiles for documentation packages
>   - make gcj native builds optional
>   - Try building java-gnome and fix any other errors
>   - Build individual tarballs, extract and try building them.

Re: [Java-gnome-developer] CVS changes

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

This is proving to be a lot trickier than I anticipated. I now have the
makefiles in java-gnome/gtk working, building a library including
glib,gdk,gtk,pango and atk (they have to be put together due to circular
dependencies). gnome,gtkhtml and glade are also working, apart from the
gcj native builds.

I'm going to stop my development now since things are working slightly.
The make scripts still need a lot of work doing to them before the
release (10 days max!). If anybody on this list knows even the slightest
about make, please could you fetch java-gnome from cvs and try building
it.


TODO: (please help)
  - find out why @GCJFLAGS@ isn't working
  - get gcj native builds working
  - get separate tarball builds working. (All my work so far has been
	trying to get the main cvs tree/all-in-one tarball to build). This
	involved writing configure scripts for each module which will find
	the required libraries, e.g. the gnome config script will replace
	@GTKJAR@ with the path to the gtk jar file, @NATIVEGTKJAR@ with the
	path to the so file, etc.
  - makefiles for documentation packages
  - make gcj native builds optional
  - Try building java-gnome and fix any other errors
  - Build individual tarballs, extract and try building them.

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

Re: [Java-gnome-developer] CVS changes

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

Sourceforge have now (impressively quickly) completed the move, after
first classifying it as high priority :)

Anonymous cvs and web based cvs are still showing the old data (should
be updated in a day or two).

Developers may now check out the new tree. I suggest doing this in a
clean directory and now taking the time to distinguish between the cvs
HEAD branch and branches to be introduced in the future (e.g. 0.8)

export CVS_RSH=ssh
mkdir jg-HEAD
cd jg-head
cvs -z9 -d :ext:dev...@cv...:/cvsroot co .

I've just added a basic README file to the main directory - please read
this first. Note that the configure scripts and makefiles are likely to
fail at the moment - they are still under development. Please try to
help get these working and test them when they are done - we need to
have this working perfectly before the next release (8 days!)

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

[Java-gnome-developer] FootNotes: Which binding set would you most like to see a part of the GNOME D&DP

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

Gnomedesktop are running a poll about which binding (has the most users
reading gnomedesktop.org). There are a few interesting and encouraging
comments about java-gnome.

http://www.gnomedesktop.org/pollBooth.php?pollID=50

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

[Java-gnome-developer] CVS changes

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

I have now moved the files to the new directory structure in cvs. I've
started work on new build scripts for these, but not yet finished.
Sourceforge help says they take up to 2 days (ex. weekends) to process
jobs, so I thought it was better to upload now in the hope that they
will do it before the weekend. I will continue trying to get the new
configure scripts and make files to work once they have installed the
changes.

I removed gnome-postal and cromagnon from cvs -- it is time for them to
move to another project. I have a backup of the current cvs - it would
be useful if other people made backups of it too before sourceforge
apply the modifications:
http://cvs.sourceforge.net/cvstarballs/java-gnome-cvsroot.tar.bz2

On Wed, Dec 10, 2003 at 01:41:45PM +0000, Mark Howard wrote:
> java-gnome/java-gnome-web
>        - website
> java-gnome/java-gnome
>        - main code tree. Includes makefiles which will build everything.
> { java-gnome/java-gnome/gtk
>  java-gnome/java-gnome/pango
>  java-gnome/java-gnome/atk
>  java-gnome/java-gnome/glib
>  java-gnome/java-gnome/glade
>  java-gnome/java-gnome/gnome
>  java-gnome/java-gnome/gtkhtml
>  java-gnome/java-gnome/vte
>  java-gnome/java-gnome/gconf
> }       - These are the main source code areas. Each will contain separate
configure.in.in's and Makefile.in.in's, which will generate *.in files
when combined with shared data from /common.
> generate separate jar files and shared libraries
> 
> { java-gnome/java-gnome/doc-core
>  java-gnome/java-gnome/doc-glade
>  java-gnome/java-gnome/doc-gnome
> }       - packages containing documentation and example applications.
> 
> java-gnome/java-gnome/build
>        - scripts to automate creation of makefiles, tarballs, etc.

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

Re: [Java-gnome-developer] (no subject)

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

On Thu, 2003-12-11 at 09:47, Mark Howard wrote:
> On Thu, Dec 11, 2003 at 09:13:51AM -0500, Jeffrey Morgan wrote:
> > gnome should be stated as libgnome, libgnomeui, and libgnomecanvas 
> > since they are all contained in our org.gnu.gnome package.
> we're not going to be able to support libgnomecanvas are we?

libgnomecanvas support has been included for some time but
I am not sure how complete it is.  We can determine if it
should be included once we perform our review of the gnome
packages.

Re: [Java-gnome-developer] (no subject)

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

On Thu, Dec 11, 2003 at 09:13:51AM -0500, Jeffrey Morgan wrote:
> gnome should be stated as libgnome, libgnomeui, and libgnomecanvas 
> since they are all contained in our org.gnu.gnome package.
we're not going to be able to support libgnomecanvas are we?

> > CVS Hacking
> > -----------
> Are you sure this can be completed and tested in order to allow us
> time to make the necessary changes prior to the 22nd?
I've just downloaded the nightly cvs tarball and will start hacking
right away. The problem is that I don't have access to the cvs
repository directly - I will have to upload the new tarball and request
sourceforge admins to install it (this is what it says to do in their
docs).
If sourceforge is not ready in time, I can create the tarballs myself
easily enough for December 22nd. In fact, I would like to have a release
before that time - 0.9.0, to test the new build scripts, multiple
tarballs and such. Then we can release 0.9.1 to send to gnome. 

> I am in favor of this move but am concerned that we might not be
> able to get everything completed prior to the 22nd.  If we do intend
> to shoot for this date we should announce our intention on the bindings
> list.
Done.

> > Released Tarballs
This is what we should send to the gnome bindings team then, to go on
the modules list -- is it ok?
http://www.gnome.org/start/2.5/bindings/modules.html

> > tarball_name    (cvs modules included)
> > libglib-java    (glib)
> > libgtk-java     (gtk+, pango, atk)
> > libgnome-java   (libgnome, libgnomeui, libgnomecanvas)
                                           ^^^^^^^^^^^^^^
										   I don't think we can
										   realistically include this.
> > libglade-java   (libglade)
Other bindings also available (soon)
> > [ libgtkhtml-java       (gtkhtml) ]
> > [ libgconf-java         (gconf)   ]
> > [ libvte-java           (vte)     ]
> > [ libgnomepanel-java (gnomepanel) ]

> > cvs hacking - Let me know if it's ok & I'll get to it
> I would say start now.  I just checked in some code so make sure
> you get the latest.
I've downloaded a nightly tarball, so will have to manually check all
changes from the last few days. I'm starting..

> Yes.  We will have more shared objects to load and finding the entry
> point for some of the libs might not be easy.
Good point. We also need to load e.g. libgnome-java-1.0 directly to
avoid problems

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

Re: [Java-gnome-developer] (no subject)

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

On Wed, 2003-12-10 at 08:41, Mark Howard wrote:
> API support
> -----------
> We should (initially) publicly announce support for glib, gtk, gnome,

gnome should be stated as libgnome, libgnomeui, and libgnomecanvas 
since they are all contained in our org.gnu.gnome package.

> libglade. We then need to urgently see how much of the upstream api we
> actually support. The current sources are based on 2.0 releases --
> there are probably many changes which are required.
> *please* can ppl volunteer to take a module each and go through this --
> either file bug reports for any API sections which we don't support, or
> produce a document listing them all (if there are many).
> We need to produce a schedule for this and make sure it is all done
> properly, ideally within the next 2 weeks. This task is probably vital
> to our joining the gnome bindings release.
> 
> CVS Hacking
> -----------
> If there are no objections, I will do this over the next few days.

Are you sure this can be completed and tested in order to allow us
time to make the necessary changes prior to the 22nd?

> Reorganise cvs:
> java-gnome/web
>         - website
> java-gnome/java-gnome
>         - main code tree. Includes makefiles which will build everything.
> { java-gnome/java-gnome/gtk
>   java-gnome/java-gnome/pango
>   java-gnome/java-gnome/atk
>   java-gnome/java-gnome/glib
>   java-gnome/java-gnome/glade
>   java-gnome/java-gnome/gnome
>   java-gnome/java-gnome/gtkhtml
>   java-gnome/java-gnome/vte
>   java-gnome/java-gnome/gconf
> }       - These are the main source code areas. Each will contain separate
> Makefile.in's (the makefiles will be generated using data from
> jg/jg/build/), /src/java/org/gnu/... and /src/jni/ trees. These will all
> generate separate jar files and shared libraries
> 
> { java-gnome/java-gnome/doc-core
>   java-gnome/java-gnome/doc-glade
>   java-gnome/java-gnome/doc-gnome
> }       - packages containing documentation and example applications.
> 
> java-gnome/java-gnome/build
>         - scripts to automate creation of makefiles, tarballs, etc.
> 
> Applications currently in cvs should be moved to separate projects --
> they are too large to be classed as example applications. Having them in
> separate projects would also be of great benefit to them. Could
> somebody please volunteer to be the maintainer for each of these and
> create a new sourceforge project?
> 
> In order to make these changes, I will download the cvs repo source and
> hack that manually. This will leave a few days where no commits can be
> mode and then everybody will have to check everything out again. It's a
> nuisance - but sadly necessary. I will start as soon as other j-g
> developers send an email saying they agree - please do this soon.

I am in favor of this move but am concerned that we might not be
able to get everything completed prior to the 22nd.  If we do intend
to shoot for this date we should announce our intention on the bindings
list.

> 
> Released Tarballs
> -----------------
> (note - these will all be created by a single script, so it won't be a
> difficult as it sounds)
> tarball_name    (cvs modules included)
> libglib-java    (glib)
> libgtk-java     (gtk, pango, atk)
> libgnome-java   (gnome)
libgnome, libgnomeui, libgnomecanvas
> libglade-java   (glade)
> [ libgtkhtml-java       (gtkhtml) ]
> [ libgconf-java         (gconf)   ]
> [ libvte-java           (vte)     ]
> [ libgnomepanel-java (gnomepanel) ]
> Items in brackets will be created and put on the website, but will not
> go in our gnome bindings module list until we are sure we can support
> them. They are in development.
> [ java-gnome    (all) ] - this is as a convenience. It will probably be
> used by everyone, especially developers and distributors (who will then
> create multiple binary packages).
> 


> Actions Summary
> ---------------
> (I'm really sorry this email got so long...)
> 
> api - somebody needs to send links to all upstream apis and changes
>    between them (any volunteers?). We all then need to check how much we
>    currently support. We need to keep a record of what checks we have
>    done.
> cvs hacking - Let me know if it's ok & I'll get to it

I would say start now.  I just checked in some code so make sure
you get the latest.

> tarballs - we'll release more of these after the cvs hackery
> focus - work more on existing bindings while there are pending bug
>    reports, then look to new libraries
> release schedule
>         22 December - tarballs. Make or break time for our inclusion in the
>         official bindings list.
>         16 Feb - API Freeze
>         22 March - bindings for 2.6 released
> parallel install - need minor code modifications

Yes.  We will have more shared objects to load and finding the entry
point for some of the libs might not be easy.

> version numbering - let me know if you disagree my proposal above
> sourceforge - anyone second my proposal

yes

> upstream - join the ml, look at webpages. Find out about development.
>    Find out what API has changed from 2.0 to 2.5
> 
> Please send comments, questions and suggestions ASAP -- to be included
> in the gnome release set we need to move very quickly.

[Java-gnome-developer] (no subject)

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

Hello,
  Sorry for such a long email -- it is important for the java-gnome
project, however, so I think it's worth it. Please send any comments or
questions you have.

  For those of you who don't know yet, some of the gtkmm developers have
proposed and in fact created and 'official' set of gnome bindings. This
means that the bindings are listed on the gnome bindings web pages as
official bindings [1]. Developers (and distributors and end users) will
therefore be far more interested in these bindings than bindings listed
in a contrib page. Being in the gnome bindings release set will show
quality and commitment. It may also lead the way for applications
developed with gnome bindings (as opposed to the standard c gnome) to be
included in the official gnome desktop release.

[1] http://www.gnome.org/start/2.5/bindings/

Java-Gnome developers have agreed in private that we should definitely
do all we can to join this group. Of course, there are quite a few
changes and guarantees we need to make -- we need to follow the rules
[2].

[2] http://developer.gnome.org/dotplan/bindings/rules.html

Summary of rules
----------------
(my proposals are in the section after this)

API support
NB: this is my interpretation of what we should be doing - there doesn't
seem to be any official version
- If we say we support a gtk/gnome module, we should support all of the
  latest version of it (e.g. for gtk+ we cannot leave out treeview
  widgets). However, small variations are acceptable, especially for
  cases which are exceedingly difficult to support in java, such as not
  including the entire drag and drop functionality
- *we* choose which modules we support. We announce these in the modules
  list [3].
- If we want to develop bindings for a new module, we can do this
  without following the schedule - making our own releases when we like,
  but they will not be listed in the modules list [3].

[3] http://www.gnome.org/start/2.5/bindings/modules.html

Release schedule
We must strictly follow the release schedule [4]. Note that this
includes first tarballs by 22 December, further tarballs roughly at 2
week intervals, API freeze and beta1 tarballs by Feb. 16th, and the
final release by Mar. 22nd.

[4] http://www.gnome.org/start/2.5/bindings/

Multiple tarballs
(many developers from many projects disagree about this).
We should have separate tarballs for each module we support. This is a
good idea - we can assign modules to developers and more easily ensure
that each module has an active developer. This will be of even more
importance as the project grows to support more of gnome. Also, it is
required by the bindings release set rules and will look good from that
perspective.  We will still create a large tarball containing
everything, which is what most people will actually use.

Version Numbers
major.minor.sub
minor = odd -- development version
minor = even -- stable release
There has not been a recommendation to follow upstream version numbers
at this stage.

Changes to be made to Java-Gnome
--------------------------------
Now for the important part. This is what I think we need to be doing
now:

API support
-----------
We should (initially) publicly announce support for glib, gtk, gnome,
libglade. We then need to urgently see how much of the upstream api we
actually support. The current sources are based on 2.0 releases --
there are probably many changes which are required.
*please* can ppl volunteer to take a module each and go through this --
either file bug reports for any API sections which we don't support, or
produce a document listing them all (if there are many).
We need to produce a schedule for this and make sure it is all done
properly, ideally within the next 2 weeks. This task is probably vital
to our joining the gnome bindings release.

CVS Hacking
-----------
If there are no objections, I will do this over the next few days.
Reorganise cvs:
java-gnome/web
        - website
java-gnome/java-gnome
        - main code tree. Includes makefiles which will build everything.
{ java-gnome/java-gnome/gtk
  java-gnome/java-gnome/pango
  java-gnome/java-gnome/atk
  java-gnome/java-gnome/glib
  java-gnome/java-gnome/glade
  java-gnome/java-gnome/gnome
  java-gnome/java-gnome/gtkhtml
  java-gnome/java-gnome/vte
  java-gnome/java-gnome/gconf
}       - These are the main source code areas. Each will contain separate
Makefile.in's (the makefiles will be generated using data from
jg/jg/build/), /src/java/org/gnu/... and /src/jni/ trees. These will all
generate separate jar files and shared libraries

{ java-gnome/java-gnome/doc-core
  java-gnome/java-gnome/doc-glade
  java-gnome/java-gnome/doc-gnome
}       - packages containing documentation and example applications.

java-gnome/java-gnome/build
        - scripts to automate creation of makefiles, tarballs, etc.

Applications currently in cvs should be moved to separate projects --
they are too large to be classed as example applications. Having them in
separate projects would also be of great benefit to them. Could
somebody please volunteer to be the maintainer for each of these and
create a new sourceforge project?

In order to make these changes, I will download the cvs repo source and
hack that manually. This will leave a few days where no commits can be
mode and then everybody will have to check everything out again. It's a
nuisance - but sadly necessary. I will start as soon as other j-g
developers send an email saying they agree - please do this soon.

Released Tarballs
-----------------
(note - these will all be created by a single script, so it won't be a
difficult as it sounds)
tarball_name    (cvs modules included)
libglib-java    (glib)
libgtk-java     (gtk, pango, atk)
libgnome-java   (gnome)
libglade-java   (glade)
[ libgtkhtml-java       (gtkhtml) ]
[ libgconf-java         (gconf)   ]
[ libvte-java           (vte)     ]
[ libgnomepanel-java (gnomepanel) ]
Items in brackets will be created and put on the website, but will not
go in our gnome bindings module list until we are sure we can support
them. They are in development.
[ java-gnome    (all) ] - this is as a convenience. It will probably be
used by everyone, especially developers and distributors (who will then
create multiple binary packages).

Releases will be made:
a) (for each module) When we want to. e.g. I would release a libglib
module now, including changes to CustomEvents which I made recently.
b) (for all public modules) When we need to create tarballs to send to
the gnome bindings release group.

Focus Shift
-----------
At present, the focus of java-gnome has been on improving api and adding
support for more gnome libraries. This has to change.
We will have to work in three modes:
* upgrades - upgrading existing bindings to the latest upstream API.
                Note that this only includes released stable modules
* maintenance - fixing bugs in released modules (e.g. gnome 2.6 release
                series when we are busy working on 2.7). This will produce
                tarballs to go into gnome 2.6.x releases. Will mostly be 
done in
                parallel with upgrade work
                (This is not an issue at the moment since we don't have any
                stable releases - it will be in the future though)
* development - Developing bindings for new modules (gconf, gtkhtml,
                panel-applet, gnome-vfs...). This will be done separately.
                Releases will be made, but will not be sent to gnome and 
will
                not follow the bindings release schedule (until they are
                complete and we put them forward for inclusion in our stable
                modules list)
The important factor about this is priorities - maintenance then
upgrades, then development - we must do things in this order.

CVS Branches
------------
In order to implement this, we will have to be more clever with cvs.

HEAD branch - development. This is where we will be most of the time
gnome2.6 branch - created once 2.6 is nearly ready for release.
j-g0.8 branch - created immediately after the cvs hacking and cleaning up
from that. This will be for bug fix releases made between now and 2.6
release.
(versions may change - see below)
NB: having the separate modules in cvs for each upstream module will
make this far easier - we will be able to branch modules at different
times depending on their development.

Release Schedule
----------------
We will release when gnome release schedule asks us to and also when we
feel like it. IMHO, releases have been far too infrequent so far for
java-gnome. The build scripts for building tarballs should make this
easier. Separate modules can be released separately.
We will differentiate stable and developmental releases.
API changes in stable releases will only happen when they do in gnome --
every 6 months.

Parallel install
----------------
We need to make sure that this is all done correctly. The java sources
need modifying to load libraries including the major.minor version
numbers; the shared libs need to be created with these numbers.
People will want to have multiple versions of java-gnome installed -
stable for their existing installed apps and developmental for their bug
fixing/development/etc..

Version Numbers
---------------
java-gnome 0.9.0 should be the next set of tarballs (Dec. 22nd, for gnome
2.5.1). These are our development releases.
java-gnome 1.0.0 will be released alongside gnome2.6

I don't think we should follow gnome version numbers - I'm not saying
why - this email is far too long already.

Move away from sourceforge?
---------------------------
CVS is unreliable.
File releases are a lot of work - uploading tarballs to an ftp server is
much easier
Bug tracking is very limited
I would like to apply for accounts on gnome.org for java-gnome project.
In addition to solving the above problems, it would be yet another sign
that java-gnome is a part of the gnome community and ppl should be using
it for their applications

Upstream contacts
-----------------
We need to stay in touch with upstream developments more closely than we
are doing at present.
If any java-gnome developer is not already subscribed to
lan...@li..., please do so now.
Also, please keep a check on the gnome bindings release pages and more
generally gnome pages.


We need help!
-------------
I know that many people read java-gnome developer without taking part in
java-gnome development. If you can spare any time at all it would be
much appreciated. I will try to help out as much as I can with new
developers, I'm sure other developers will do too. The main priority at
the moment is checking how much of the gnome api we implement -
somebody will send another email in a few days with links to the
upstream API reference, changes between 2.0 and 2.5 and our own api
reference - please volunteer to look through a small section of this.


Actions Summary
---------------
(I'm really sorry this email got so long...)

api - somebody needs to send links to all upstream apis and changes
   between them (any volunteers?). We all then need to check how much we
   currently support. We need to keep a record of what checks we have
   done.
cvs hacking - Let me know if it's ok & I'll get to it.
tarballs - we'll release more of these after the cvs hackery
focus - work more on existing bindings while there are pending bug
   reports, then look to new libraries
release schedule
        22 December - tarballs. Make or break time for our inclusion in the
        official bindings list.
        16 Feb - API Freeze
        22 March - bindings for 2.6 released
parallel install - need minor code modifications
version numbering - let me know if you disagree my proposal above
sourceforge - anyone second my proposal
upstream - join the ml, look at webpages. Find out about development.
   Find out what API has changed from 2.0 to 2.5

Please send comments, questions and suggestions ASAP -- to be included
in the gnome release set we need to move very quickly.

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

[Java-gnome-developer] Meeting in Boston?

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

Are there any java-gnome users living in the Boston area?
I am going to be in Boston for the next couple of days and
would be interested in getting together with you to discuss
the project if you are interested.  Please send email to me
directly (off of this list) if you are interested.

-Jeff

RE: [Java-gnome-developer] FileSelection Dialog

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

Take a look at the testgtk example in src/examples/gtk.
It demonstrates this widget and how to determine which
button was pressed.

> According to the gtk documentation the "filename" 
> property contains "The currently selected filename".
> The behavior you are seeing is the behavior of the
> underlying widget.  You will need to check if the
> user presses the OK or Cancel button.
> 
> -Jeff
> 
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Hoping someone can help me with what should be quite 
> straight forward!
> > 
> > I have a the following code:
> > 
> > final FileSelection dialog = new FileSelection("Select File");
> > 
> > dialog.setModal(true);
> > dialog.addListener(new DialogListener() {			
> > 	public boolean dialogEvent(DialogEvent event) {
> > 		if (event.isOfType(DialogEvent.Type.RESPONSE)) {
> > 			String filename = dialog.getFilename();
> > 		}
> > 
> > 		((Dialog) event.getSource()).destroy();
> > 		return true;
> > 	}
> > });
> > dialog.show();
> > 
> > 
> > So what happens is the file selection dialog opens. I select my file
> > (say /home/work/build.xml) and click oK, the filename 
> > variable correctly
> > contains the selected file.
> > Now the problem is, if I select this file, but click cancel.
> > I still end up with text in my filename variable, when I want it to
> > contain nothing, because I didn't really choose a file.
> > 
> > Anyone clear this up for me?
> > 
> > Thanks,
> > - --
> > [A n d r e w]
> > - ------|------
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.3 (GNU/Linux)
> > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> > 
> > iD8DBQE/0SCb2AKtqeH2FeQRArcwAJ9yD/Jr73aHHbb7D7FYKtRckH7FYgCaAm0P
> > rdDC16FIrRVEt/6+H/V9aX0=
> > =e/et
> > -----END PGP SIGNATURE-----
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign 
> > up for IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell 
> > to sys admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > java-gnome-developer mailing list
> > jav...@li...
> > https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> > 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign 
> up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell 
> to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> 

RE: [Java-gnome-developer] About Dialog

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

What other directories are in your LD_LIBRARY_PATH?  Do
they include the directory that contains your gnome shared
objects?  The error reported means that it is finding the 
java-gnome library but when it calls the gnome method
gnome_about_new to create the gnome about dialog it is unable
to locate that lib.  

-Jeff


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mark Howard wrote:
> | Try doing it with the LD_LIBRARY_PATH rather than the -D:
> |
> | export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
> | java ...
> |
> 
> I just checked my LD_LIBRARY_PATH, and it is already set to 
> /usr/local/lib
> 
> So I think there must be another problem.. :(
> 
> - --
> [A n d r e w]
> - ------|------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQE/0k5h2AKtqeH2FeQRAhAjAKCiK99Do/UBdXvpN2iwLPaPSSLirACeLxgR
> llXDhd7bhhCICdG7uYC1t1w=
> =7nMp
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign 
> up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell 
> to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> 

RE: [Java-gnome-developer] FileSelection Dialog

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

According to the gtk documentation the "filename" 
property contains "The currently selected filename".
The behavior you are seeing is the behavior of the
underlying widget.  You will need to check if the
user presses the OK or Cancel button.

-Jeff

> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hoping someone can help me with what should be quite straight forward!
> 
> I have a the following code:
> 
> final FileSelection dialog = new FileSelection("Select File");
> 
> dialog.setModal(true);
> dialog.addListener(new DialogListener() {			
> 	public boolean dialogEvent(DialogEvent event) {
> 		if (event.isOfType(DialogEvent.Type.RESPONSE)) {
> 			String filename = dialog.getFilename();
> 		}
> 
> 		((Dialog) event.getSource()).destroy();
> 		return true;
> 	}
> });
> dialog.show();
> 
> 
> So what happens is the file selection dialog opens. I select my file
> (say /home/work/build.xml) and click oK, the filename 
> variable correctly
> contains the selected file.
> Now the problem is, if I select this file, but click cancel.
> I still end up with text in my filename variable, when I want it to
> contain nothing, because I didn't really choose a file.
> 
> Anyone clear this up for me?
> 
> Thanks,
> - --
> [A n d r e w]
> - ------|------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQE/0SCb2AKtqeH2FeQRArcwAJ9yD/Jr73aHHbb7D7FYKtRckH7FYgCaAm0P
> rdDC16FIrRVEt/6+H/V9aX0=
> =e/et
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign 
> up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell 
> to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
> 

Re: [Java-gnome-developer] About Dialog

[Luca De R. <pie...@li...>]

Il dom, 2003-12-07 alle 19:26, Andrew ha scritto:
> Hi,
> I am about to go on holidays, but will probably work a bit on it with my
> laptop.
Fine! Maybe, you could discuss eventual changes on the list, prior to
send patches, to avoid conflicts, or just to know other people's
opinion.

> The About window is not a glade window, it is a default gtk window.
Ehr...I was simply guessing that that signal defined from within glade
could be the problem, but it doesn't seems to be. (it's a Gnome widget).

> The reason I'm confused about it not working in my application is
> because it works when I run the CroMagnom application from eclipse, in
> exactly the same manner.
> I have the jar files in /usr/local/share/java-gnome
It continues to sound like a PATH problem: are you able to run cromagnon
and launch its about dialog *without* eclipse?
I can't think anything else but a compilation issue, be sure to check
configure output, during the build process, if it says it's missing some
needed library.

Luca.