Roman,
The changes you are talking about are probably far reaching and sound
somewhat like the fb-toolkit proposal itself. This is tantamount to
replacing
the entire AWT and 2D stack and I don't see that as a useful goal.
As noted in my initial email to the fbtoolkit proposal, toolkits are not
pluggable, nor was
there any design intent that they ever should be.
fb-toolkit is a separate project. I expect it will remain so for the
forseeable future.
-phil.
Roman Kennke wrote:
Hi there,
At the moment I'm trying to get GNU Classpath's GTK peers (and a handful
of own peer/graphicsenv implementations for embedded systems) working
with OpenJDK. I'm encountering a couple of problems and I ask myself if
the OpenJDK project has any interest in patches to improve support for
external toolkits.
For example, there's a bunch of places with code like this:
private void initPeer() {
if (Toolkit.getDefaultToolkit() instanceof HeadlessToolkit){
peer =
((HeadlessToolkit)Toolkit.getDefaultToolkit()).createKeyboardFocusManagerPeer(this);
}
if (Toolkit.getDefaultToolkit() instanceof SunToolkit){
peer =
((SunToolkit)Toolkit.getDefaultToolkit()).createKeyboardFocusManagerPeer(this);
}
}
Obviously, this wouldn't work with anything except the built-in
toolkits.
Other areas where I suspect big problems are fonts and probably images.
It seems like OpenJDK has no support for a pluggable font implementation
at all. However, the GTK peers rely on their own implementation (which
is abstracted behind an extension of FontPeer).
With the new FB-Toolkit project approved, I'd guess that there would be
interest in developing a clean(er) interface and allowing alternative
peers and graphics environments to be plugged in, is that correct? If so
I would prepare some patches soon.
/Roman
