<AWT Dev> RFC: KeyboardFocusManager patch

[Anton V. Tarasov]

Hi All,

Ok, let's think again what we're fighting for.
Developing a custom Toolkit (not really pluggable de-facto) is not
an every day task. It's not adding a listener to a component.
This is not what a developer would periodically run into creating
his application. This is a pretty complicated, large-scale task.
Actually, implementing a dummy KFMPeer (if it's not supposed to use)
would be an insignificant additional effort against the whole
background. That is, we don't probably need to add a whole class to
our code in order to save a bit of time of the developer.
So, "less changes" position seems really reasonable.

As NPE would be not as informative here as ClassCastException (that would
also point just at the right place in the code) I'd suggest to just
directly cast the Toolkit to KFMPeerProvider. Severely but concisely.

Thanks,
Anton.

Oleg Sukhodolsky wrote:
> 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.