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

Re: [Java-gnome-developer] SIGSEGV (cont)

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

Avi,

This bug was fixed.  You should get a copy of the latest code from
CVS.  Per Dan's ealier reply, you might wish to wait for a day or
two as we are currently releasing much code.

-Jeff

On 2000.12.06 22:01:57 -0500 Avi Bryant wrote:
> 
> Hmmm... it seems like the problem is in the GtkEditable classes, or
> perhaps all classes dealing with strings... and it's not just with
> reflection.  With CVS code, the following test crashes:
> 
> import gtk.*;
> 
> class GtkTest {
> 
> 	public void callback(String a, int b, int c) {
> 	}
> 	
> 	public static void main(String args[]) {
> 
> 		Gtk.init(args.length,args);
> 
> 		GtkEntry e = new GtkEntry();
> 		e.signalConnect("insert_text", "callback", new
> GtkTest());
> 		e.setText("hello world");
> 	}
> }
> 
> It's possible to get the same crash with 0.5.0 code pretty easily as
> well.
> I'm over my head here...
> 
> ---------- Forwarded message ----------
> Date: Wed, 6 Dec 2000 13:53:08 -0800 (PST)
> From: Avi Bryant <av...@be...>
> To: jav...@li...
> Subject: SIGSEGV
> 
> 
> I'm getting segmentation faults using java-gnome... I'll try to narrow it
> down more exactly, but it seems to involve using java.lang.reflect from
> within a signal callback.  Some data points: using java-gnome 0.5.0, I
> get
> the error on Method.invoke and Field.set with the blackdown JDK, but only
> on Field.set with the IBM JDK.  Using the CVS sources, I get the crash on
> both JDKs for both reflection types.
> Note that this only happens when I'm inside a callback... it's not a
> general problem with reflection.
> 
> Can anybody reproduce this?
> Does anybody have any clue what's going on?  
> 
> avi
> 
> 
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> http://lists.sourceforge.net/mailman/listinfo/java-gnome-developer
> 

Re: [Java-gnome-developer] SIGSEGV (cont)

[Dan B. <da...@mi...>]

Avi Bryant writes:
>Hmmm... it seems like the problem is in the GtkEditable classes, or
>perhaps all classes dealing with strings... and it's not just with
>reflection.  With CVS code, the following test crashes:

We're just about to switch over to totally rewritten code to do type
conversions (and in particular, strings), and we already have new callback
handling code that will be in the next release, so the problem may
just-go-away. But, just in case, I'll try out your specific example with
the new stuff (probably this weekend); hopefully all will be well.

Thanks.

-dan

[Java-gnome-developer] SIGSEGV (cont)

[Avi B. <av...@be...>]

Hmmm... it seems like the problem is in the GtkEditable classes, or
perhaps all classes dealing with strings... and it's not just with
reflection.  With CVS code, the following test crashes:

import gtk.*;

class GtkTest {

	public void callback(String a, int b, int c) {
	}
	
	public static void main(String args[]) {

		Gtk.init(args.length,args);

		GtkEntry e = new GtkEntry();
		e.signalConnect("insert_text", "callback", new GtkTest());
		e.setText("hello world");
	}
}

It's possible to get the same crash with 0.5.0 code pretty easily as well.
I'm over my head here...

---------- Forwarded message ----------
Date: Wed, 6 Dec 2000 13:53:08 -0800 (PST)
From: Avi Bryant <av...@be...>
To: jav...@li...
Subject: SIGSEGV


I'm getting segmentation faults using java-gnome... I'll try to narrow it
down more exactly, but it seems to involve using java.lang.reflect from
within a signal callback.  Some data points: using java-gnome 0.5.0, I get
the error on Method.invoke and Field.set with the blackdown JDK, but only
on Field.set with the IBM JDK.  Using the CVS sources, I get the crash on
both JDKs for both reflection types.
Note that this only happens when I'm inside a callback... it's not a
general problem with reflection.

Can anybody reproduce this?
Does anybody have any clue what's going on?  

avi

[Java-gnome-developer] SIGSEGV

[Avi B. <av...@be...>]

I'm getting segmentation faults using java-gnome... I'll try to narrow it
down more exactly, but it seems to involve using java.lang.reflect from
within a signal callback.  Some data points: using java-gnome 0.5.0, I get
the error on Method.invoke and Field.set with the blackdown JDK, but only
on Field.set with the IBM JDK.  Using the CVS sources, I get the crash on
both JDKs for both reflection types.
Note that this only happens when I'm inside a callback... it's not a
general problem with reflection.

Can anybody reproduce this?
Does anybody have any clue what's going on?  

avi

Re: [Java-gnome-developer] Java applet support

[Dan B. <da...@mi...>]

Kim Lassila writes:
>I guess the question is: Is it possible even in theory to add Gtk/Gnome
>widgets to an applet window?

I think it'd be theoretically possible to create a separate GTK window from
within an applet, assuming the right libraries were linked in and the
security manager was appropriately configured, but my guess is that it
won't be possible to attach GTK widgets to a pre-existing AWT window, such
as would be found within a web page.

-dan

Re: [Java-gnome-developer] libglade support?

[Dan B. <da...@mi...>]

Avi Bryant writes:
>Is anyone working on incorporating libglade into java-gnome?  If I take a
>crack at it, is anyone else interested?

Jeffrey Morgan (Fearless Leader) writes:
>The team is currently trying to enhance/expand our support of GDK, GTK,
>and the core GNOME libraries. [...] If you want to work on this please
>feel free. I should warn you that the bindings are under constant
>development and change frequently. That only makes our work more fun:)

Let me second that opinion. My guess is that it'll still be a month or so
until the base bindings have reached a semblance of stability, and at that
point, there *still* won't be a lot of the usual conveniences that one gets
in the base GTK because the bindings won't actually be complete yet. So,
work done at the glade level would be subject to a lot of ebbs and flows
in the underlying stuff until more of it is pinned down.

All that being said, I personally am looking particularly forward to being
able to use an interactive GUI development tool with Java-Gnome, since I'm
not very adept at writing GUI code myself.

-dan

[Java-gnome-developer] Java applet support

[Kim L. <kl...@tu...>]

Hello everyone,

I am new to the project and could not find any information about
possible support for Java applets. It would be awesome to write
Gnome applets that run in Mozilla. I understand that this would require
the binding libraries to be present in the client computer, but still
I would love it.

I guess the question is: Is it possible even in theory to add Gtk/Gnome
widgets to an applet window?

-- 
  __
 /_/\ Kim Lassila
 \_\/ kl...@tu...

Re: [Java-gnome-developer] libglade support?

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

I believe Olivier worked on this a little over a year ago.  Currently
nobody is
working on a libglade binding.  The team is currently trying to
enhance/expand
our support of GDK, GTK, and the core GNOME libraries.  We also hope to add
more examples and enhance our documentation.  We have discussed bindings
for
gnome-print and gnorba or Orbit.  libglade support is something that would 
be nice to have although it is not our top priority at this time.

If you want to work on this please feel free.  I should warn you that the
bindings are under constant development and change frequently.  That
only makes our work more fun:)

-Jeff



On 2000.11.28 19:43:23 -0500 Avi Bryant wrote:
> Is anyone working on incorporating libglade into java-gnome?  If I take a
> crack at it, is anyone else interested?
> 
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> http://lists.sourceforge.net/mailman/listinfo/java-gnome-developer
> 

[Java-gnome-developer] libglade support?

[Avi B. <av...@be...>]

Is anyone working on incorporating libglade into java-gnome?  If I take a
crack at it, is anyone else interested?

[Java-gnome-developer] Re: Error while running GTK-Test

[Jean v. W. <je...@sm...>]

Hi Otmar,

On Fri, 24 Nov 2000, Otmar Struwe wrote:

> After installing GTK-Java-0.5.0. (configure --wiht-gkt-only , make, make install), I tried to run the BigTest-Example.
>  
> I got an error from java:
>  
>   error in loading shared library 
>    /usr/local/lib/libGTKJava.so.0.5.0: undefined symbol: gtk_init
>  
Which java/JDK version did you use to compile the the library?  Which version
did you use to run it?  One problem that I had once was that I had two java
versions.  The one was the one I compiled withi, the other one was kaffe.
Since I only typed: java -classpath ... BigTest I got the same error.  It used
Kaffe instead of the JDK I thought.  You have to set the LD_LIBRARY_PATH
environmental variable for kaffe to work correctly.

Check with `which java` or java -version to ensure that you are using the
JDK/JRE you think you are using.  If you have kaffe and you inadvertently used
that java you can fix it by saying:

export LD_LIBRARY_PATH=<path to libraries>

NOTE  Make sure that you do not trash your old LD_LIBRARY_PATH when doing it.
For more information see the FAQ on java-gnome.sourceforge.net.
>  
> I checked with ldconfig for the shared libraries "libGTKJava" and "libGKT". Both libraries are set.
>  
> I am working with SUSE 6.4, GKT-Version 1.2.8. and the IBM- and/or Blackdown-Port for JDK-1.3.
>  
If you have success with getting it workng  please let me know.  If you have
any more queries please feel free to contact me or someone else on the list.

> Any idea whats wrong ?
>  
>   Otmar

Regards
Jean

[Java-gnome-developer] Error while running GTK-Test

[Otmar S. <otm...@we...>]

After installing GTK-Java-0.5.0. (configure --wiht-gkt-only , make, make install), I tried to run the BigTest-Example.
 
I got an error from java:
 
  error in loading shared library 
   /usr/local/lib/libGTKJava.so.0.5.0: undefined symbol: gtk_init
 
 
I checked with ldconfig for the shared libraries "libGTKJava" and "libGKT". Both libraries are set.
 
I am working with SUSE 6.4, GKT-Version 1.2.8. and the IBM- and/or Blackdown-Port for JDK-1.3.
 
Any idea whats wrong ?
 
  Otmar
 
 
> 


_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

[Java-gnome-developer] Error while running GTK-Test

[Otmar S. <otm...@we...>]

After installing GTK-Java-0.5.0. (configure --wiht-gkt-only , make, make install), I tried to run the BigTest-Example.
 
I got an error from java:
 
  error in loading shared library 
   /usr/local/lib/libGTKJava.so.0.5.0: undefined symbol: gtk_init
 
 
I checked with ldconfig for the shared libraries "libGTKJava" and "libGKT". Both libraries are set.
 
I am working with SUSE 6.4, GKT-Version 1.2.8. and the IBM- and/or Blackdown-Port for JDK-1.3.
 
Any idea whats wrong ?
 
  Otmar
 
 
> 


_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

[Java-gnome-developer] Error while running GTK-Test

[Otmar S. <otm...@we...>]

After installing GTK-Java-0.5.0. (configure --wiht-gkt-only , make, make install), I tried to run the BigTest-Example.

I got an error from java:

error in loading shared library 
  /usr/local/lib/libGTKJava.so.0.5.0: undefined symbol: gtk_init


I checked with ldconfig for the shared libraries "libGTKJava" and "libGKT". Both libraries are set.

I working with SUSE 6.4, GKT-Version 1.2.8. and the IBM- and/or Blackdown-Port for JDK-1.3.

Any idea whats wrong ?

 Otmar



_______________________________________________________________________
1.000.000 DM gewinnen - kostenlos tippen - http://millionenklick.web.de
Ih...@we..., 8MB Speicher, Verschluesselung - http://freemail.web.de

[Java-gnome-developer] Update

[Jeff M. <ku...@ne...>]

All,

I have just released code into cvs that will break existing code.
I apologize for this but it was necessary to accomplish an overhaul
of the signal/callback mechanism.  In most cases you can just replace
a call to signal_connect(...) with signalConnect(...) and it should
work.  But if you want to take advantage of some of the enhancements
you will need to make a few more changes.

The online javadoc reflects the change.  You can look at the
javadoc for the class GtkObject.  I have tried to make the
comments in the javadoc as clear as possible but if you have
questions please don't hesitate to post to this list.  The 
javadoc is located at:

http://java-gnome.sourceforge.net/Documents/javadoc/index.html

Also, the test applications and all of the examples under 
src/examples have been updated to reflect the changes.  
I have also updated the tutorial.

Finally, I have also fixed the bug that occurs in all methods
that return a String.  This is also in cvs.  For those of you
who only have the 0.5 release, I would suggest you get a copy
from cvs.  There have been many fixes and enhancements made
over the last two weeks.

-Jeff

Re: [Java-gnome-developer] JDK's

[Paul G. <pau...@bi...>]

Jean van Wyk wrote:
> ...
> Can you guys please let me know which JDK's/JRE's you use.  I would really
> appreciate it if you could also give me some details on the header files
> and the class files as well.

I use Sun JDK 1.3 on Red Hat 7.0.  I use jikes whenever i can for the
compile phase because it is so fast.

Headers
-------
$JAVA_HOME/include
$JAVA_HOME/include/linux

Classes
-------
$JAVA_HOME/jre/lib/rt.jar

There are also i18n.jar, javaplugin.jar, javaplugin_l10n.jar, and
sunrsasign.jar in the same directory, but i'm not sure whether these are
needed.  I put them in my $CLASSPATH at the end just in case.

> This will be used in part for the FAQ and in
> part to improve the configure script so that we can detect the different
> version and their differences.

I'd really like to see jikes override javac by default in the configure
script, or at least an option to allow it to do so.  I'd also be happy
to use Kaffe as my default environment, as it's provided with Red Hat,
but since the FAQ said it didn't work, i downloaded Sun's version.

Paul
---------
"He must become greater; i must become less." - John 3:30
http://www.bigfoot.com/~paulgear

[Java-gnome-developer] JDK's

[Jean v. W. <je...@sm...>]

Hi there,

Can you guys please let me know which JDK's/JRE's you use.  I would really
appreciate it if you could also give me some details on the header files
and the class files as well.  This will be used in part for the FAQ and in
part to improve the configure script so that we can detect the different
version and their differences.  You can send it directly to me at
je...@sm....

Here is a few as an example
-----------------------------------------------------------------------------
Blackdown 1.1.7:
Headers
-------
$(JAVA_HOME)/include
$(JAVA_HOME)/include/genunix  (From memory so this may be wrong)
Classes
-------
$(JAVA_HOME)/lib/classes.zip

IBM JDK 1.1.8:
Headers
-------
$(JAVA_HOME)/include
$(JAVA_HOME)/include/linux
Classes
-------
$(JAVA_HOME)/lib/classes.zip

IBM JDK 1.3:
Headers
-------
$(JAVA_HOME)/include
Classes
-------
$(JAVA_HOME)jre/lib/rt.jar

Kaffe 1.0.5:
Headers
-------
$(JAVA_HOME)/include/kaffe
Classes
-------
$(JAVA_HOME)/share/kaffe/Klasses.jar
-----------------------------------------------------------------------------

Thank you very much for your time.

Regards
Jean

[Java-gnome-developer] Update

[Jeff M. <ku...@ne...>]

Javadoc documentation is now available on the Java-GNOME web site. 
Although not very detailed, it can be used to determine what features
are available in the bindings.  It can also be used as a reference tool.
The url is:

http://java-gnome.sourceforge.net/Documents/javadoc/index.html

If you need a feature that is not currently available in the bindings
you can request an enhancement.  Our goal is to make the binding
as useful as possible.  We would be very interested in knowing
what you would like to see added.  Enhancement requests can be
entered via our bug tracker.  Please make sure you select a 
Bug Group of "Enhancement Request".  The url is:

http://sourceforge.net/bugs/?func=addbug&group_id=1522

The Java-GNOME development team has finished the planning for the next
release of the binding.  The following features and enhancements are 
scheduled to appear in 0.5.1:

* Support for GnomeUIInfo
* Generation of javadoc with method level comments
* Enhancements to the signal/callback mechanism
* Enhancements to the Enum/Type system (internal)
* Shorten the names of enums (ex. GdkEventMask.GDK_EXPOSE_MASK to
  GdkEventMask.EXPOSE_MASK)
* Support for kaffe build
* Support for more GDK/GTK/GNOME widgets/functions
* More examples
* Updates to documentation

We are hoping to have this release available before the end of
the year.  If you can't wait, all source is available via anonymous
cvs.  For instructions on how to access cvs for this project 
please see:

http://sourceforge.net/cvs/?group_id=1522

Thanks for your interest.
-Jeffrey Morgan

Re: [Java-gnome-developer] Re: your mail

[Paul G. <pau...@bi...>]

Oskar Liljeblad wrote:
> 
> [I am forwarding this email to the list. I hope you didn't mind. :)]

Not at all!  I personally am very glad to see some discussion between
the
two projects.

> On Monday, November 13, 2000 at 12:41, Morgan, Jeffrey wrote:
> ...
> > The purpose of my email is to establish communications and to see where
> > our two projects might collaborate.  Although we are trying to accomplish
> > different goals, some commonality might be beneficial to the Java and
> > GNOME community.  At a minimum, it might be nice if we could offer the
> > same APIs.
> ...
> I have provided a list of differencies between the two projects on the
> homepage of Gnome-GCJ. It is at
> http://gnome-gcj.sourceforge.net/java-gnome.html. Consider it a preliminary
> source of details to be discussed. The list may contain some deficiencies,
> so feel free to comment on it. (I think this list would be a good place, if
> you don't mind.)

Osk, i read your list, and i'd like to make a few comments from the
perspective of someone who's looking for the ideal balance between
development
& runtime environments for programming on Linux.  (Aren't we all?  :-)

> ...
> JG uses JNI - supports almost all java environments. (GG only gcj.) 

I've mentioned on this list before why i think it would be great if GG &
JG
could offer the same APIs: I can develop with a rapid development system
or
non-gcc compiler (i prefer Jikes because it's so blazingly fast), but
then
deliver with gcj and gain the speed increase afforded by compiled code.

> GG uses automake/autoconf/libtool, JG only autoconf. 
> GG's generator programs are more extensive and powerful (IMHO). 
> JG's generator programs seem to be better documented. 
> The input for the generator programs are not the same in JG and GG. JG uses
> a format similar to the Gtk/Gdk .defs files, while GG uses a custom format.
> JG appears to have more active authors than GG. 
> JG uses CVS on SourceForge, GG doesn't. 

Most of these are of little importance to application developers, as
long as the software works, is stable, and is available from a reliable
site.

> JG's latest version released in november, GG's latest in september. 

The less frequently, the better.  Free software is too hard to keep up
with
already.  :-)

> GG is probably harder to build because there is no stable libgcj/gcj
> release. 

I think you can take that 'probably' out.  I would say "GG is nearly
impossible to get working if you can't/don't want to build your own
gcc/gcj/libgcj."  I have tried a number of versions from my vendor (i
use Red
Hat 7.0), and i just can't get the thing to work.  Recompiling gcc, etc.
is
not an option, as i don't have the disk space, or the time to work out
what i
can free up on my hard drive.

> API differencies

FWIW, here are my comments on the API differences...

> GG uses gnu.{gdk,gtk,gnome} as package, JG just {gdk,gtk,gnome}. 
> GG strictly follows Sun's naming standards for classes and methods (not
> packages). JG does most of the time, but not always
> (signal_connect vs signalConnect). 
> JG uses class names like GtkButton, GtkWindow. GG uses Button, Window.

I prefer GG's naming on all counts above.

> This causes problems with GdkPixmap vs GtkPixmap (vs
> GnomePixmap), which is solved by using names like those in JG (GdkPixmap
> etc). 

I think this approach by GG is OK, as long as the one that is most
likely to be frequently used is left unadorned (e.g. have GdkPixmap,
GtkPixmap, and gnu.gnome.Pixmap, or some other similar scheme).  One
other option is to call them all Pixmap, and make people select which
one they are referring to manually.

> JG uses separate classes for all enum/flag-set in Gtk I.e. GtkAttachOptions,
> GdkCursorType, GdkEventType, GdkEventMask. 
> JG uses objects to represent contants.
> This leads to a massive number of classes, and probably slower overall
> execution because of more objects in memory. Some might reason
> that this makes programming painful, but it adds safety.

I prefer the approach that provides better type safety, even if it adds
memory
or CPU overheads.

> JG uses long constant names: GdkEventMask.GDK_EXPOSURE_MASK.
> Compare to GG's Gdk.EXPOSURE_MASK (in future Event.EXPOSURE_MASK). 

Shorter names are preferable, as long as they are non-ambiguous and
there is no information loss in the name.  e.g. There is no need to have
GDK_ in a constant since there is a gdk in the package name.  However,
taking out the 'EventMask' in the current GG naming style does mean that
some meaning is lost.  The future GG one where the full name would be
something like gnu.gdk.Event.EXPOSURE_MASK sounds good to me.

> JG supports some API simplification by method shadowing. GG doesn't yet. 
> JG allows generic callbacks (like ActionListener in AWT).
> I.e. 
> 
> b.signalConnect("clicked", new Callback() {
>     public void action(Object source, Object data) { .. }
> }
> JG also allows direct connection to methods, i.e.
> b.signal_connect("clicked", "buttonClickedMethod", this); 
> GG generates specific listener classes for all known signals. This allows
> additional arguments to the signals (such as GdkButtonEvent to the
> "button_event" signal) to be passed to Java.  JG discards them. GG will
> change entirely to support all of these with GLIB 2.0. 

Those are all nice features.

> Nearly all classes and methods are javadoc-documented in GG. (Although it
> only refers to the C API - no factual documentation is provided.) 

Not much point in providing the documentation if it only refers to the C
API -
just running javadoc on a class file would be good enough if that is the
case...

> GG's GTK and GDK API seems to be more complete? 
> JG's Gnome API seems to be more complete? 

While the union of these two sets would be really nice to have :-), with
respect to getting consistent application look & feel, Gnome APIs are a
little more important.

> GG doesn't strictly name Java methods after C functions. (gtk_button_pressed
> becomes firePressed, not pressed etc). 

The GG style, which is more Java-like (i.e. all methods are verbs), is
preferable to me.

> JG doesn't seem to completely support association of Java objects with
> native objects (the peers concept). Without this, methods that return Java
> objects are impossible. A great deal of time has been spent on GG to make
> the peer system as smooth and safe as possible. 

A complete peer system would be most helpful if we need to provide
advanced
functionality or work around specific problems/limitations in the API.

Paul
---------
"He must become greater; i must become less." - John 3:30
http://www.bigfoot.com/~paulgear

[Java-gnome-developer] Re: your mail

[Oskar L. <os...@he...>]

[I am forwarding this email to the list. I hope you didn't mind. :)]

On Monday, November 13, 2000 at 12:41, Morgan, Jeffrey wrote:
> Hello,

Hi Jeff!

> My name is Jeff Morgan and I am the project leader on the Java-GNOME
> project.  This project has been dormant for about a year but has
> recently be resurrected. Currently the Java-GNOME project is under
> heavy development.

That's good to hear! (For the record, Gnome-GCJ has been "frozen"
for some months. I haven't been working on it. I hope to revive it
with GLIB 2.0 and GTK 2.0 soon.)

> The purpose of my email is to establish communications and to see where our
> two projects might collaborate.  Although we are trying to accomplish
> different goals, some commonality might be beneficial to the Java and
> GNOME community.  At a minimum, it might be nice if we could offer the
> same APIs.

Ah, that sounds like a great idea. Actually, I don't think our goals are
that much different. GCJ, the compiler/Java environment which Gnome-GCJ
is aimed towards, does already support JNI. Gnome-GCJ currently generates
CNI, but it is technically possible to make it generate JNI as well.
(Of course it would require a lot of extra manual glue code, but I still
think it is doable.)

You say that "At a minimum, it might be nice if we could offer the same
APIs". I would rather say "At a maximum" :) Providing the same API would be
ideal. But it will not be that simple I guess... There are some fundamental
differencies between Java-GNOME (JG) and Gnome-GCJ (GG). Take for example
the way Gtk/Gdk constants are used. In GG they are passed as int's - in JG
(AFAIK) each constant is a separate object in a class for that set of
constants (enum/flags).

I have provided a list of differencies between the two projects on the
homepage of Gnome-GCJ. It is at
http://gnome-gcj.sourceforge.net/java-gnome.html. Consider it a preliminary
source of details to be discussed. The list may contain some deficiencies,
so feel free to comment on it. (I think this list would be a good place, if
you don't mind.)

I am open to discussion. It would be really nice if we could improve
our libraries by sharing - if not code then at least ideas. :)

Regards,

Oskar Liljeblad (os...@he...)

[Java-gnome-developer] updates in CVS

[Morgan, J. <Jef...@rp...>]

All,

The 0.5 build that was released last Friday had a bug that caused certain
combinations 
of distros and JDKs to have an unsatisfied link error when running a Java
program that 
imported gnome.*.  This has been fixed and is now in CVS.

Also, I checked code into CVS that allows the definition of primitive field
types and
enhances the error checking in the generated JNI code.

-Jeff

Re: [Java-gnome-developer] gnome-gcj

[Dan B. <da...@mi...>]

Paul Gear writes:
>Given the technologies they are aiming at (one is compiled Java, the
>other interpreted; one uses CNI, the other JNI, etc.), it may be a
>little difficult to combine the projects, but as a developer i'd be very
>interested in seeing some co-operation between the projects such that
>they have the same Java API.

(Note, I'm a developer who recently joined the Java-Gnome team, and while I
am relatively familiar with the project at this point, I certainly don't
claim to write policy for the group!)

I think there's a reasonably good chance of that happening: GTK is itself
relatively "OO" for a C library (the official GTK metadata has a
define-object construct), so there's a pretty natural correspondence
between GTK types and classes in an OO language. The Java-Gnome project is
pretty much sticking to the GTK line when it comes to associating functions
with classes.

The places where it gets fuzzy are in things like callbacks, where there is
no obvious single "right way" to do the mapping. The Java-Gnome project
is still wrestling with this issue in particular, but no doubt there's more
grey area than that.

The other obvious arbitrary difference is what package to put the classes
in. The Java-Gnome project settled on the top-level packages "gdk", "gtk",
and "gnome" for classes corresponding to those respective pieces of the
toolkit.

Personally, I'd be happy to see a gnome/gtk mapping that worked the same
across Java VMs/implementations. Right now, I think JNI is more widely
supported than CNI, so I'm happy to be working on that first. (Actually,
getting totally un-altruistic for a moment, the one app I care most about
using gtk happens also to require the audio support only available right
now with Sun's JDK 1.3, so I'm most interested in seeing GTK work there
right now.) Of course, there are people who probably care more about
compiling with gcj than running on a JNI-capable VM, and that's
understandable too.

I definitely hope that at some point the projects merge, or align, or
whatever, of course. There's almost certainly some amount of duplicate
effort going on right now (e.g., both projects have to generate Java source
files corresponding to the GTK types, based on the same ".defs" files). I'm
willing to live with that for now, though.

-dan

Re: [Java-gnome-developer] gnome-gcj

[Paul G. <pau...@bi...>]

Adrian Vance Custer wrote:
> 
> Hello everyone,
> 
> Good of you to resurrect this project. Since I haven't heard reference to
> another similar project, i'm bringing it to everyone's attention to be sure
> that you are not duplicating efforts. If both projects are to continue, please
> mention your reasoning in the FAQ.
> ...
> If these
> projects overlap as much as I think they do, they could effectively be
> combined. If you  alreadly knew about gnome-gcj, then ingnore this.

Given the technologies they are aiming at (one is compiled Java, the
other interpreted; one uses CNI, the other JNI, etc.), it may be a
little difficult to combine the projects, but as a developer i'd be very
interested in seeing some co-operation between the projects such that
they have the same Java API.

If that were the case, i could do my prototyping in interpreted Java
(jikes is _so_ much faster than any other compiler!  :-) and then switch
to compiled for the final application where the platform permitted it. 
That would be very cool.

Paul
---------
"He must become greater; i must become less." - John 3:30
http://www.bigfoot.com/~paulgear

[Java-gnome-developer] gnome-gcj

[Adrian V. C. <ac...@no...>]

Hello everyone,

Good of you to resurrect this project. Since I haven't heard reference to
another similar project, i'm bringing it to everyone's attention to be sure
that you are not duplicating efforts. If both projects are to continue, please
mention your reasoning in the FAQ.

You all know of the gcj component of the Gnu Compiler Collection (gcc). THis
has been moving pretty fast and is getting quite usable. Swing is a longer way
away so Oskar Liljeblad decided to implement gnome-gcj. He seems to have moved on to
other things recently as he got little help. (I never could get the
gcc/gcj/gnome-gcj combination compiled). His project is also on sourceforge at
http://gnome-gcj.sourceforge.net. His email is osk_at_hem.passagen.se. If these
projects overlap as much as I think they do, they could effectively be
combined. If you  alreadly knew about gnome-gcj, then ingnore this.

Keep up the good work
adrian
acuster_at_nature.berkeley.educational

[Java-gnome-developer] I couldn't help myself

[Dan B. <da...@mi...>]

I went ahead and implemented the passing of arguments of enumerated types
as I outlined. I think this made the C compile get a lot cleaner, in that
I'm getting much fewer warnings of the form:

    glue/gnome_GnomeFontPicker.c: In function `Java_gnome_GnomeFontPicker_setMode':
    glue/gnome_GnomeFontPicker.c:123: warning: passing arg 2 makes pointer from integer without a cast
    glue/gnome_GnomeFontPicker.c:125: warning: passing arg 2 makes pointer from integer without a cast

My changes ended up exposing another preexisting problem, though, which is
almost certainly the cause of some (potential) crashes. Namely, the
generator cannot deal at all with pointer-to-enum. I found one place where
an attempt was made to define such a function (gnome_doc_get_item_by_name).
I didn't look too hard, so I could've missed a bunch, for all I know. With
my version, this particular example failed to compile entirely (because the
type was specified as an enum, not as a pointer to enum--gcc merely warns
for implicit int-to-pointer conversions but will issue an error for
implicit enum-to-pointer). After fixing the type declaration, I found that
the generator doesn't really distinguish "enum type" from "array of enum
type" very well. I commented the one place in gnome.defs where this
mattered, and left it at that for now.

My thoughts on the matter are this:

* In the case I found, the only reason for using a pointer was to get
  multiple return values from a method. It may make sense to have a more
  general mechanism for specifying output arguments, rather than relying on
  C semantics, and attempting to reproduce those semantics in Java. For
  example, we might want to automatically declare a "return value from
  method x" class for each method that does this sort of thing, and then,
  on the Java side, have such an object passed in as a "secret parameter".

* If there's a need, we also might want to bite the bullet and define
  classes that represent arrays of enumerated types. Such objects would
  really just hold an internal int[], and this would be what is passed in
  to the native method, via a similar unwrapping mechanism to how simple
  enumerated types now work. The Java interface to the object, though,
  would always intern the ints into the appropriate class on the way out.

On a final note: While I did get everything working, I'm not totally happy
with the structure of the code. In particular, I ended up doing type
reasoning in MethodDefinition in a couple places, which probably would be
better done in TypeDefinition. (I didn't quite understand how the classes
were interacting at first, and so I tended to try to make my changes in a
minimally intrusive way.) Basically, there probably ought to be a method in
TypeDefinition that returns the Java type corresponding to the JNIType (I
called it the "unwrapped type" below). Here's an example:

    Java type:            "GtkCellType"
    Java unwrapped type:  "/* GtkCellType */ int"
    JNI type:             "/* GtkCellType */ jint"
    Native type:          "GtkCellType"

The thing that's missing is a method which returns the unwrapped type. The
thing that figures that out is hard-coded into MethodDefinition in a couple
of places.

Anyway, since I don't have time to do anything more significant this
weekend (and my place d'emploi probably wouldn't like it if I spent my day
working on Java-Gnome), I figured that I'd leave things alone for now, but
that someone else or I could refactor the code later. I left "FIXME"s in
the code in the couple of places where it matters.

I've created patches both against the original sources and against my
update from yesterday. I'll put them on sourceforge, but they're also here:

  Full diffs from the cvs repository:
    <http://condensed.milk.com/~danfuzz/java-gnome/full-diffs.txt>

  Just the diffs from today's work:
    <http://condensed.milk.com/~danfuzz/java-gnome/enum-diffs.txt>

Take care, and hope everyone's weekend was a good one,

-dan

[Java-gnome-developer] Another possible change or two to the calling conventions?

[Dan B. <da...@mi...>]

I was looking through the generated C code and noticed, wit respect to my
recent patch on return types, that there's a similar issue with how
enumerated types are passed as arguments. Although I think the code as
written does execute correctly (assuming 32 bit pointers), it involves slow
JNI calls and questionable casts, so I'd be in favor of rewriting it (which
I'd be happy to do).

Here's an example of the problem, looking at GtkBox.setChildPacking.
The Java code says this:

    native public void setChildPacking(GtkWidget child, boolean expand,
    boolean fill, int padding, GtkPackType pack_type);

The C signature is this:

    JNIEXPORT void JNICALL Java_gtk_GtkBox_setChildPacking (JNIEnv * env,
    jobject obj, jobject j_child, jboolean j_expand, jboolean j_fill, jint
    j_padding, /* GtkPackType */ jint j_pack_type)

Note the last argument. Java is passing a pointer (object reference), but
the C function is accepting a 32-bit int instead (hence the problem with
non-32-bit-pointer architectures). Then in the C code, the jint is
(implicitly) cast back to a jobject to extract out the "value_" instance
variable:

    jfieldID fid_arg4;
    jclass cls_arg4;
    jint _arg4;
    [...]
    cls_arg4 = (*env)->GetObjectClass(env, j_pack_type);
    fid_arg4 = (*env)->GetFieldID(env, cls_arg4, "value_", "I");
    _arg4 = (*env)->GetIntField(env, j_pack_type, fid_arg4);

JNI is notoriously slow, so I wouldn't recommend doing this. Rather, I'd
do the thing I did with return values, but in the other direction. The
Java code would look like this:

    public void setChildPacking(GtkWidget child, boolean expand,
        boolean fill, int padding, GtkPackType pack_type) {
        setChildPacking0(child, expand, fill, padding, pack_type.getValue());
    }

    native public void setChildPacking0(GtkWidget child, boolean expand,
    boolean fill, int padding, int pack_type);

The C code in question would just be this:

    JNIEXPORT void JNICALL Java_gtk_GtkBox_setChildPacking (JNIEnv * env,
        jobject obj, jobject j_child, jboolean j_expand, jboolean j_fill,
        jint j_padding, /* GtkPackType */ jint j_pack_type) {
    [...]
    GtkPackType _arg4;
    [...]
    _arg4 = (GtkPackType) j_pack_type;

How does this sound?

Also, again for JNI avoidance reasons, it might be advisable to do the
jobject->nativepeer argument conversion in a different way than is
currently done. Concrete suggestions: Cache the JNI fieldID object
per-class so that instance methods can grab the nativepeer out of "this"
with only one JNI call (instead of 3). And pass nativepeer values directly
as parameters, unwrapping them inside Java in the same way as I propose for
enumerated types, above.

-dan