Roman Kennke wrote:
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?
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.
Well, actually the question is whose side to take. For us, the 1st approach
is better, for consumers - the 2nd. But taking into account that not many
apps will survive without focus, the both are almost equal.
Thanks,
Anton.
