pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Bartlett <cbartlet...@gmail.com>
Subject Re: KeyListeners on ImageView
Date Fri, 04 Mar 2011 13:38:00 GMT
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 <gk_brown@verizon.net> 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 <bill.van.melle@gmail.com> 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
>
>
>

Mime
View raw message