<AWT Dev> RFC: KeyboardFocusManager patch
Konstantin.Voloshin at Sun.COM
Thu Jun 21 11:04:18 PDT 2007
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
public abstract class DummyToolkit // Or "CustomToolkit"
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.
More information about the awt-dev