<AWT Dev> RFC: KeyboardFocusManager patch
Phil.Race at Sun.COM
Thu Jun 21 20:07:22 PDT 2007
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.
Konstantin Voloshin wrote:
> I'd choose Roman's completely silent variant, as most simplistic, and
> as throwing less exceptions ( that is "no exceptions" :) ).
> And to give "food for thought" to custom Toolkit implementers, we can
> introduce e.g.:
> public abstract class DummyToolkit // Or "CustomToolkit"
> extends Toolkit
> implements KeyboardFocusManagerPeerProvider
> public KeyboardFocusManagerPeer createKeyboardFocusManagerPeer(
> KeyboardFocusManager manager )
> return new DummyKeyboardFocusManagerPeer();
> And succeeding "pluggable" points could also fit there.
> Roman Kennke wrote:
>> Hi Anton,
>>>> I think both approaches are fine and have more or less the same
>>>> The 1st throws the exception a little earlier. If the reasoning is to
>>>> notify the implementor that there's something missing, this might be
>>>> better because it will pop up even in the smallest HelloWorld example.
>>>> But I guess there will be some initial focus setup on any window, so
>>>> this is not really an argument. Why do you think the 2nd is
>>> Just because it leaves the implementor a chance not to do additional
>>> work he probably doesn't want to. Say, if he believes he will live
>>> focus at all (a custom headless toolkit, or kbd-less devises etc.).
>>> Not very useful, of course, but theoretically possible.
>> Not really. When we throw an exception from the DummyKFMPeer, then the
>> application will not come up properly. This is why I started this in the
>> first place (ok, I got an NPE instead of some other execption, but that
>> doesn't really matter). My reasoning with the DummyKFMPeer was indeed to
>> leave this open (yes, some apps can indeed live without focus). It could
>> be a good idea then to issue a warning only, rather than throwing an
>> exception from the DummyKFMPeer methods.
More information about the awt-dev