Well, it seems that virtualization of already implemented GUI-logic is
finally coming to being desirable.
It may seem fatally hard, and could indeed be so, sometimes. But I like
this idea a lot (in general), and nothing yet have convinced me, that
it's not worth to try and go in this direction.
Of course, there're strong limitations on changing public API. Moreover,
they are reasonable, and I'd not propose to fight them,.. in foreseeable
future. Instead, to increase flexibility and reusability, I'd go for
internal refactorings. Actually, I'm doing so every time I have the chance.
It's hard to plug inside AWT, because IMO it's internals are far from
being decomposed into logically "orthogonal" components (I mean
classes/interfaces, not widgets). But for me, it's not the reason to
avoid changing it, but rather the reason to do that decomposition, step
by step. Which would help not only in plugging, but also in having less
bugs, being easier to develop new features, and whatever else
refactoring leads to.
As for some practical tricks, to avail pluggaility into AWT's internals
without intrusive changes into public API. I imagine some "policy"
side-classes can be introduced, e.g. available for being overridden by
users, e.g. used as a "factory" of pluggable components.
And this Roman's idea sounds corresponding to what I think/wrote:
Roman Kennke wrote:
...
> nope I don't. I'd introduce an interface (e.g.
> sun.awt.KeyboardFocusManagerPeerProvider), let SunToolkit,
> HeadlessToolkit and my Toolkits implement this and check+call against
> the interface :-)
...
Konstantin
Roman Kennke wrote:
Hi Phil,
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.
I don't know. I was able to get a small AWT Hello World program running
with the OpenJDK and the GTK peers in half an hour (basically extending
the GTK peers to implement some stuff in the peer interfaces that wasn't
implemented yet).
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.
There's the peer interfaces which doesn't seem so bad, even if there was
no design intent behind them. At least, in GNU Classpath land we could
live quite well with it, even to the extent that we had 3 different
working sets of AWT peers /GraphicsEnvs, each of them even supporting
their own widgets, graphics, font and image implementations. Granted, we
extended the peer interfaces at some points (mostly fonts), but nothing
'tantamount'.
I'll just post some patches and you tell me what you think, ok?
Cheers, Roman
