pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gk_br...@verizon.net>
Subject Re: KeyListeners on ImageView
Date Fri, 04 Mar 2011 13:45:41 GMT
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
> 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
>> 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
>> Chris

View raw message