<AWT Dev> RFC: KeyboardFocusManager patch

[Roman Kennke]

Hi Phil,

> 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

I'm sure it's a bigger project. Let's do it step by step and not give up
because the mountain seems so high ;-)

> - fullscreen works
This is already abstracted out nicely AFAIR and an implementation detail
for the GraphicsEnvironment and friends.

> - toolkit images work
Dito.

> - 2D can render to component graphics
Dito.

> - fonts are the same
Fonts are a problem because there's no interface in place as far as I
can see.

> - swing works
That's the goal ;-)

> - printing works
I think this is an implementation detail too.

> 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.

Sure. Let's take it step by step. Also, looking at your concerns above,
I have the feeling that you misunderstood something. My concern is
factoring out the necessary interfaces to be able to plug an alternative
implementation in (actually, most of this is already done and only needs
some additions in some places). This is not about implementing a fully
different toolkit.

> So you might need to end up replacing everything via SPIs that don't exist
> and haven't been contemplated.

Many interfaces actually do exist. There's the stuff in java.awt.peer,
java.awt.dnd.peer as well as GraphicsEnvironment, GraphicsConfiguration
and GraphicsDevice, plus the Toolkit class. This already covers many
many aspects of such an interface. The only big missing thing is fonts.

> 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.

Can't we keep that as something inofficial? I mean, I need it to support
a bunch of toolkits and stuff that I already have in place, but there is
no need to document that in the specs etc. It's an internal interface,
just like the peer interface is now, and it's not recommended for public
use.

> 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.

Can you explain what CCC is? Is that a good thing or a bad thing? ;-)

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

Hmm, why? This patch seems pretty small and un-intrusive.

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

Good question. I think it uses some GTK function to print to the
graphics object (which is based on Cairo). Yes I think this is also
using postscript at some level.

Cheers, Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt