<AWT Dev> RFC: KeyboardFocusManager patch

[Roman Kennke]

Hi,

> My comments concern the DummyKFMPeer (KFM is an acronym
> for KeyboardFocusManager commonly used in talks here).
> I thought that it's not good to leave it blank and that we're
> better to concretize the case when a custom Toolkit doesn't
> implement KFMPeerProvider interface. Let's consider the following
> two approaches:
> 
> 1. We don't create the DummyKFMPeer at all, instead
> we throw some proper exception if the Toolkit doesn't
> implement the KFMPeerProvider (i.e. we force it to implement).
> For instance, we just throw ClassCastException.
> 
> 2. We create the DummyKFMPeer and make its every method throw
> OperationNotSupportedException.
> 
> The both approaches serve to notify the implementator of the Toolkit
> that it should probably have to provide some logic for the KFMPeer.
> In case he "forgot" to do it but addressed the peer he would implement,
> if he didn't need it and he didn't address the peer - nothing happens,
> when he didn't need it but still addressed he'd make it silent.

Sounds reasonable to me. I wasn't sure what would be the best way, but
let the KFM throw NPEs didn't seem wise.

> The second approach is less strict and is rather more preferable.

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?

/Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-0
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt