This is the mail archive of the
java-patches@sources.redhat.com
mailing list for the Java project.
Re: Merging in more AWT stuff
On Tue, Aug 15, 2000 at 08:58:54PM -0600, Tom Tromey wrote:
>[...]
> What parts of the dependency diagram would be useful in other
> situations? For instance, what could be shared with the Gtk peers?
A quick overview:
(Most of the text is from
<URL:http://www.ii.uib.no/~rolfwr/jcnix/packages.html>. Extra comments
has been added after each section, highlighting the usefulness the code
in each package.)
no.rwr.x
A Java interface to Xlib. This is where development started.
This is where all the all the Xlib native code is located. As
with X, this package gives access to mechanism, but does not
dictate policy. This package has no significant outward
dependencies.
Required by the X toolkit, is of no use to the Gtk peers, is
also useful for making Java/libgcj based X clients without
using AWT.
no.rwr.xutil
Contains various support classes that make it easier to
implement X clients using the no.rwr.x package. Development on
b this package has mostly been abandoned, in favor of making a
proper AWT toolkit based on the no.rwr.x package. However,
this package contains a lot of useful code for creating new
toolkits that are not AWT specific. All code in this package
is pure Java, and only build on top of the classes in no.rwr.x.
Of no use to libgcj.
no.rwr.data
Utility classes that can be used to manipulate the data buffers
defined in java.awt.image. Is used by the implementation of
some of the classes in java.awt.image to make the code cleaner.
All code in this package is pure Java.
Classes useful for libgcj has been imported to gnu.gcj.awt.
no.rwr.util
Misc. general purpose classes.
Classes that are used by the java.awt.image implementation
has been imported to gnu.gcj.awt.
no.rwr.image
Package that contains routines to convert between color formats
defined in java.awt.image. Contains APIs that makes it possible
given two image formats, to find the best optimized renderer
to convert image data from the one format to the other. All
code in this package is pure Java. The no.rwr.image package
can now offload work to dedicated libraries such as
no.rwr.image.hermes, or falls back on pure Java implementations
that use the conversion code contained in java.awt.image.
Useful for most toolkits and Java2D implementations. However,
it needs an overhaul to address the needs of Java2D.
no.rwr.image.hermes
Package that contains native code that interfaces the Hermes
library. This is a specialized (LGPL, portable) library for
doing image data conversion (and little else), that will employ
things such as optimized MMX assembler, if available, to do the
most efficient conversion possible. The no.rwr.image.hermes
package conforms to a pluggable renderer interface, that makes
the Hermes support optional, and will allow other rendering
libraries to be implemented.
Useful for any toolkit that doesn't have equivalent
functionality. The Gtk toolkit will probably use some
combination of gdkrgb, libart, pixbuf instead.
no.rwr.image.codec.libjpeg
Package that contains native code that interfaces the IJG
JPEG library to allow JPEG images to be loaded into the image
buffers defined by java.awt.image. The idea is that this
package should be pluggable, but this has not been done yet.
Useful for any toolkit, but the Gtk toolkit will probably
rely on pixbuf instead.
no.rwr.awt.x
An AWT toolkit for the X Window System. This is a specific
implementation of java.awt.Toolkit and the component peer
classes. This implementation uses the classes from no.rwr.x to
create an AWT toolkit that works under the X Window System.
This implementation targets the 1.3 AWT API, and abstractions
such as GraphicsDevice are mapped into X11 screen/visual
combination. All code in this package is pure Java. The code
depends on some code from the no.rwr.awt package to implement
general AWT policies that are hidden behind the scenes of the
AWT API.
This is the actual X toolkit code. All the code in this
package is only useful for the X toolkit implementation.
no.rwr.awt
Package that contains general purpose AWT support classes.
These classes are not toolkit specific, but can be used by any
toolkit implementation to implement some of the mechanisms that
takes place behind the scenes of the AWT API.
The code in this can be very useful for any toolkit
implementation, including the Gtk toolkit. This package
contains code for correctly redirecting events to
lightweight components, and the beginnings of a Java2D
rendering pipeline.
javax.swing, javax.swing.border, javax.swing.plaf, javax.swing.event
The beginnings of a clean room implementation of the Swing
API. Since X11 does not have an inherent widget set, all
widgets used by the X toolkit are implemented in pure Java.
Swing consists of an API to pure Java components. The idea is
to implement portions of Swing, and use Swing components as
heavyweight peers in the X toolkit. Eg. an java.awt.Button has
a button peer that is implemented using javax.JButton.
Using Swing components as native AWT components is probably
only useful for the X toolkit. However, these packages
contains the foundation for a proper Swing implementation,
that can be used by any toolkit.
no.rwr.plaf
The beginnings of a specific Pluggable Look and Feel for
Swing. The current plan is to create a look and feel similar
to GTK. In a long term perspective, it would be nice to
abandon this package and make SkinLF (GPL; GTK and KDE
Theme Support) from L2F Productions work with the clean room
implementation of Swing.
> I don't feel any particular anxiety to get it in. Sooner is better,
> of course, but it is also important to make sure things are done in an
> intelligent way. It's pretty much your call.
I'll take a stab at moving in the core of the X toolkit when I get the
time.
>[...]
> Rolf> Actually, I'd like to see it being possible run several
> Rolf> different toolkits concurrently.
>
> That would be cool. Is it really possible?
I think it can done. The root of the containment hierarchies
of AWT components determine which toolkit to use. By overriding the
getToolkit() method of a top-level component class (such as Frame), an
application programmer can choose which toolkit to use for all children
of such top-level components. It is thus possible to have several
containment hierarchies using different toolkits, simply by controlling
what the getTookit() method of the root components return.
There are however some pitfalls. One must always be sure the to use the
correct toolkit instance when calling Toolkit methods.
Eg. creating an image:
// BAD:
img = Toolkit.getDefaultToolkit().createImage(producer);
// BETTER:
img = targetComponent.getToolkit().createImage(producer);
// BEST:
img = targetComponent.createImage(producer);
... and images cannot be create for components before they have been
given their proper place in the containment hierarchy.
--
Rolf W. Rasmussen