Xlib AWT peers and Java 2D

Tom Tromey tromey@cygnus.com
Sun Oct 8 15:33:00 GMT 2000

>>>>> "Rolf" == Rolf W Rasmussen <rolfwr@ii.uib.no> writes:

Rolf> I've been working a bit on merging in my X based AWT toolkit.


Rolf> I've stubbed out dependencies on other parts of my codebase,
Rolf> which means that operations such as image loading will currently
Rolf> not work, and image operations will use the slow fall-back
Rolf> implementations in the java.awt.image classes.

How does your non-Java image loading work?  Do you use things like
libtiff, libjpeg, etc?

Rolf> gnu.gcj.xlib: The CNI based Xlib classes. 

This one is definitely fine.

Rolf> gnu.awt.xlib: The X based AWT peer toolkit.
Rolf> gnu.awt.j2d: The Java 2D graphics pipeline classes.
Rolf> gnu.awt: Misc. support classes I envision would be useful for any
Rolf> 	 AWT toolkit implementation.

Maybe this should be raised on the Classpath list as well.

Classpath tends to use gnu.java.awt.* (ie, more full path name).
For the peers they would use gnu.java.awt.peer.xlib.*.

I don't think anybody definitively sets policy for the gnu.*
hierarchy.  However, between us and Classpath we can probably make the

I don't have very strong opinions on this topic, as long as the names
are descriptive.

Rolf> I've made some Makefile.am and configure.in changes that seem to
Rolf> be working, but are probably horribly wrong.  Someone with more
Rolf> experience with these things should probably take a look at it.
Rolf> Tom?

Do we want to put the X .class files into libgcj.zip or into another
zip file?  Do we even want to build the .class files for this code at
all?  For the peers it seems like nothing will need to read those
.class files.

Do we want to link libgcjx against the X libraries?

For the configure change, I think you need to test "$no_x" and not
"$have_x".  (According to the docs for AC_PATH_X in the autoconf

It seems like you also need to use X_CFLAGS in the Makefile, at least
when building the C++ code that uses X.

But otherwise the Makefile change looks fine to me.

Rolf> The current patch will build the Xlib dependent code into a
Rolf> separate library named libgcjx.so.  Is this a good idea?  The
Rolf> alternative; making libgcj.so dependent on Xlib, seems like a
Rolf> poor solution.

It definitely should be a separate library.  We shouldn't require Xlib
in every gcj-compiled program.

I think the library's name should be picked so that the Toolkit class
will dynamically load it automatically via Class.forName.  So for
instance if the `awt.toolkit' property would be set to
`gnu.java.awt.peer.xlib' to get this toolkit, then we could name the
library `gnu-java-awt-peer-xlib.so'.

Likewise the Gtk peers should be built as their own library.

Rolf> And finally, the current patch does not enable any components
Rolf> such as buttons, labels or list, only basic components such as
Rolf> windows, frames, canvases and panels.

I don't know what to do here either.

I don't know anything about Swing (I have a book on it but haven't had
time to read it).  

Rolf> However, I'm having difficulty seeing how an GTK based Swing
Rolf> could be implemented without seriously altering the underlying
Rolf> assumptions on how the painting mechanism works.

I don't know the answer.  But could it be done if we could modify Gtk?
That might be possible (though I don't have any inside knowledge about
it or anything like that).

Rolf> Another issue is how to map the open-ended data models for JTree
Rolf> and JTable to the data models of their GTK equivalents.

Maybe in some cases we'd have to write new Gtk widgets.


More information about the Java-patches mailing list