I was thinking= more about adding a little (optional) flexibility regarding Pivot's cu= rrent focusability of Components. =A0Being able to make an ImageView focusa= ble 'solves' the issue from the original post in this thread, but c= onversely, being able to quickly disable the focusability of a Component mi= ght be a simpler way for developers to manage a Container's focus compa= red to creating a custom FocusTraversalPolicy. =A0Both of these are relativ= ely straightforward to code at present, but a setFocusable(boolean) method = would reduce the amount of code required. =A0It could be provided with a ca= veat that changing the value from its default may have consequences as you = mentioned, and may not be a complete solution (absence of a graphical indic= ation of focus).

Anyway, I'm not sold either way at present. =A0

If someone thinks it is a good idea and wants to push it, feel free!= =A0Some example use cases would certainly help.

C= hris

On 4 March 2011 19:44, Greg Brown= <gk_brown@ver= izon.net> wrote:

I had a similar thought. Unfortunately,= making a Window focusable will break apps that currently call window.reque= stFocus() to focus the content component. Those apps would have to change t= o call window.getContent().requestFocus(). That's not out of the questi= on, but seems wrong - container focusability was added primarily to support= composite components like Spinner rather than layout or navigation compone= nts, or windows.

I'd be surprised if this is actually a common issue in p= ractice, though. In most applications, some component generally has the foc= us, so key strokes will be propagated to the window. What is the use case f= or sending key strokes to a window when nothing is focused? How would we kn= ow 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/KeyLi= steners-on-ImageView-tp2600622p2600622.html)

On 4 March 2011 11:35, Bill van Melle <= bill.van.melle@gmail.com> wrote:

I shouldn't have to stand on my head cr= eating a focusable subclass of WindowSkin. (Admittedly, Chris has shown tha= t 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 eas= ily to change focusability? Each Component would maintain its current defa= ult focusability, but this could be toggled with a simple call to pivotCo= mponent.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/Contain= er 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 sti= ll create a custom skin which would paint the indicator (or add a condition= al Decorator).

They could also supply a FocusTraversalPolicy to Containers to meet the= ir individual needs.

Chris