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
