<AWT Dev> Better support for external Toolkits/GraphicEnvs

[Konstantin Voloshin]

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