<AWT Dev> pluggable AWT peers/graphicsenv

[Konstantin Voloshin]

 > ... 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.
...
 > ... IMO this would result in
 > a better archtictured AWT for everybody. ...

I think these are good ideas. As we all seem not knowing the more or 
less exact future and interaction of/between OpenJDK, JDK7, other 
OpenJDK projects, we probably should start with reaching that future 
step by step. Just as with that small KFM-patch. Or probably with Roman 
starting a new branch, and us all seeing what comes out of attempts to 
integrate it into JDK7 afterwards :)

P.S.
Branches/merges are a troublesome thing. But I like to think that, if 
code is good, merging shouldn't be deadly hard.


Roman Kennke wrote:
> 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