<AWT Dev> RFC: KeyboardFocusManager patch

[Phil Race]

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.

-phil.


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 
>>>> effect.
>>>> 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 
>>>> preferable?
>>>>
>>> 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 
>>> without
>>> 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.
>>
>> /Roman