Ah, OK - that makes sense. I believe Swing also allows you to do this. It could be handled similarly to how preferred width and height can be overridden by the component.
On Mar 4, 2011, at 8:38 AM, Chris Bartlett wrote: > Greg, > > I wasn't specifically thinking about Windows and both understand and agree > with your reasoning regarding where keyboard events would be sent. > > I was thinking more about adding a little (optional) flexibility regarding > Pivot's current focusability of Components. Being able to make an ImageView > focusable 'solves' the issue from the original post in this thread, but > conversely, being able to quickly disable the focusability of a Component > might be a simpler way for developers to manage a Container's focus compared > to creating a custom FocusTraversalPolicy. Both of these are relatively > straightforward to code at present, but a setFocusable(boolean) method would > reduce the amount of code required. It could be provided with a caveat that > changing the value from its default may have consequences as you mentioned, > and may not be a complete solution (absence of a graphical indication of > focus). > > Anyway, I'm not sold either way at present. > If someone thinks it is a good idea and wants to push it, feel free! Some > example use cases would certainly help. > > Chris > > On 4 March 2011 19:44, Greg Brown <[email protected]> wrote: > I had a similar thought. Unfortunately, making a Window focusable will break > apps that currently call window.requestFocus() to focus the content > component. Those apps would have to change to call > window.getContent().requestFocus(). That's not out of the question, but seems > wrong - container focusability was added primarily to support composite > components like Spinner rather than layout or navigation components, or > windows. > > I'd be surprised if this is actually a common issue in practice, though. In > most applications, some component generally has the focus, so key strokes > will be propagated to the window. What is the use case for sending key > strokes to a window when nothing is focused? How would we know which window > to send them to? > > > > On Mar 4, 2011, at 4:31 AM, Chris Bartlett wrote: > >> CCed to the Dev mailing list where it is perhaps best to continue the >> discussion >> (Some context for the Dev list >> http://apache-pivot-users.399431.n3.nabble.com/KeyListeners-on-ImageView-tp2600622p2600622.html) >> >> On 4 March 2011 11:35, Bill van Melle <[email protected]> wrote: >> I shouldn't have to stand on my head creating a focusable subclass of >> WindowSkin. (Admittedly, Chris has shown that it's easy to do, but it seems >> wrong to make everyone do it.) >> >> I wonder if there is a case to be made for adding a setFocusable(boolean) >> method to Component which could be used easily to change focusability? Each >> Component would maintain its current default focusability, but this could be >> toggled with a simple call to pivotComponent.setFocusable(true/false) rather >> than the need for sub-classing.. >> >> Changing a normally focusable Component to be non-focusable should not cause >> any problems, but changing a normally non-focusable Component/Container to >> be focusable would probably mean that there is no graphical indicator that >> the Component has focus. If a user really needed this they could still >> create a custom skin which would paint the indicator (or add a conditional >> Decorator). >> >> They could also supply a FocusTraversalPolicy to Containers to meet their >> individual needs. >> >> Chris > >
