<AWT Dev> RFC: KeyboardFocusManager patch

[Phil Race]

Hello Roman,

My big concern is that in order to get this right so that everything
matches up its a lot more than this, ie to get to where

- fullscreen works
- toolkit images work
- 2D can render to component graphics
- fonts are the same
- swing works
- printing works

quite a lot of this is about the inter-relationship of the toolkits
and 2D that just isn't neatly factored out. I don't actually know
what all the problems would be, I just know that its not been
considered.
So you might need to end up replacing everything via SPIs that don't exist
and haven't been contemplated.

Also if we expose interfaces here we have to define them - its
a chunk of work to spec out something like that and it constrains
our implementation in the future.

We have rules (internal to date) that say *any* interface we
expose, not just java api, but right down to commands, command line
args, system properties, env variables which are documented
etc etc is an 'interface' in the general sense and has some
level of support associated with it. I am not sure we want
to take escalations from Oracle because a pluggable interface
doesn't work when it was not designed to be a true pluggable interface.
Hence CCC approval seems required unless someone can
figure out if anything that's discussed on openjdk is not
considered an exposed interface .. but I don't see how that
can be the case.

BTW Terminology is a bit of a stumbling block here.
We use the term opendjk to refer to the community and the projects
with in it, and at the same time use openjdk to refer to the jdk 7
project as it stands in open source. Although some one else will
tell me the jdk 7 project is really just another project within
the openjdk community ...

So I think you can do this as a project *within* the openjdk
community but hold off on changes to the jdk 7 project itself
until more details are apparent.

I am actually somewhat interested in the idea of AWT widgets
no longer looking like "motif" and instead using GTK widgets -
although we have a compatibility issue there.
On the flip side, pretty much everyone uses swing these days.
AWT widgets don't get used much, so I'd wonder if there's
really going to be that much call for it.

If the AWT group accept this patch then they will need
to get CCC clearance first.

I'd also like to see you look further down the road as to
what other changes are needed first, and what does and doesn't
work.

BTW what does Component.printAll() in your current implementation?
Does it print the GTK peers as postscript, as we do for the motif
widgets?

-phil.

Roman Kennke wrote:
> Hi Phil,
> 
>> Again this (toolkit etc)  is not a pluggable API/SPI. What can be hacked 
>> up is not supportable.
>> There would need to be a CCC OK for this and we don't even have the 
>> governance in place
>> for that.  open jdk has basically stalled all CCC's anyway which is a 
>> pain I would like to go away but
>> so far hasn't.
>> So this  may be interesting to look at this but its a project and not 
>> patches to the product.
> 
> If you're really not interested going further with this I have an easy
> solution. I can hack up something in private (I am going to do this
> anyway so that I can support the various alternative AWT peer
> implementations that we already have in place), upload the patches to
> some public location (to conform with the GPL) and be happy with it. I
> feel that doing this together with you would be a better solution (less
> maintenance for me and a better architectured AWT for you) but I don't
> need to do this if you don't feel like it's a good idea.
> 
> /Roman
>