[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-swing-dev
Subject:    <Swing Dev> pluggable AWT peers/graphicsenv
From:       roman.kennke () aicas ! com (Roman Kennke)
Date:       2007-06-22 12:54:37
Message-ID: 1182516877.6166.57.camel () mercury
[Download RAW message or body]

Hi all,

I am crossposting this because I think this could affects all GUI
development (mainly AWT and J2D, but also a little Swing) in some way or
another. There really should be a gui-dev mailing list for things like
this.

I am plannig to implement the missing pieces to make the AWT/Java2D
implementation 'pluggable', thus separating the abstract stuff in
java.awt from the actual implementation. The goal is to be able to
provide alternative implementations for the AWT widgets and the Java2D
stack. This is actually for a significant part already finished in
java.awt.peer (and some classes in java.awt). This works pretty well now
for the widgets and important parts of Java2D with OpenJDK and external
GTK peers [1]. Also, the AWT implementation of GNU Classpath can serve
as a proof-of-concept and source of inspiration. There we already
support 3 different AWT/J2D implementations (GTK, Qt and plain X) all of
which have their own native widgets, fonts, graphics and images. The
JamaicaVM has a some more implementations for a couple of embedded
systems. Another example is the newly approved fbtoolkit implementation
which basically plugs into the java.awt.peer interfaces too.

The biggest road block to this right now seems to be the font
implementation which is (afaics) the only area in J2D which isn't
abstracted out nicely. The other areas should require little to no work,
as it is already provided by the peer interfaces and the
GraphicsEnvironment and friends classes.

Note also that I don't intent to touch the public API. I consider this
fine as it is and we shouldn't spoil it more than it is now
(java.awt.Toolkit, ugh). Also note that I don't intent to introduce
another toolkit/j2d implementation, but 'only' refactor what is there
now so that it is _possible_ to do.

There seems to be some serious scepticism about this [2][3] which might
be a good thing. So I'm pondering whether it is worth the effort doing
this inside OpenJDK or if I should rather do it in an external project
(avoiding the f-word here), with the option to merge the changes in
later down the road. I'd think that this is better done inside OpenJDK,
especially with the valuable input of you all. IMO this would result in
a better archtictured AWT for everybody. On the other hand, if I do this
externally you wouldn't be bothered so much with stuff that you have no
interest in anyway and I could probably progress faster.

I'd like to hear your opinions on that issue with the goal to reach a
decision whether we should try to develop that inside OpenJDK or if I
should better do it separately. I'd also like to keep the technical
considerations low (let's do that if we decide for yes). I know it's
possible to do and I am going to do this anyway, the question is as part
of OpenJDK or not.

[1] http://kennke.org/blog/2007/06/21/gtk-peers-on-openjdk/
[2] http://mail.openjdk.java.net/pipermail/awt-dev/2007-June/000050.html
[3] http://mail.openjdk.java.net/pipermail/awt-dev/2007-June/000040.html

Cheers, Roman
-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



[prev in list] [next in list] [prev in thread] [next in thread]