<AWT Dev> RFC: KeyboardFocusManager patch

[Oleg Sukhodolsky]

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.

Since an absence of good/correct implementation of KFMPeer may cause 
some hard to investigate focus problems I'd vote for throwing some 
exception, because we do not have another good way to warn a developer.


I personally like an idea to have DummyKFMPeer throwing those 
exceptions.  But from the other hand, throwing an exception in 
initPeer() minimize changes :)  So, as a lazy person, I have to say that 
this approach even better (both have advantages and disadvantages and so 
I choose the shortest one :)

Oleg.