<AWT Dev> RFC: KeyboardFocusManager patch

[Konstantin Voloshin]

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