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 Wed, 09 Mar 2011 12:16:47 GMT
Key events go to the currently focused component, of which there may be only one at any given
time. Generally, the focused component is a descendant of the active window. However, there
are cases where you want the active window to remain unchanged but pass focus to another window
- for example, in a tree node or table row editor. You wouldn't want the popup window that
handles the edit to "steal" the active state from the main window, right? That would seem
very odd from a UI perspective.

Re: active windows and displays - like the focused component, there is one and only one active
window, regardless of the number of displays. Think of a display like another monitor. Your
OS does not allow you to have one active window per monitor - there is still only one active
window regardless of how many monitors you have.

Pivot's definition of focus is not significantly different from other UI toolkits - key events
go to the focused component. The problem appears to be the handling of keystrokes when no
component has the focus (i.e. the focused component is null). I agree that sending keystrokes
to the display in that case makes sense.


On Mar 8, 2011, at 8:55 PM, Chris Bartlett wrote:

> OK, I see what you are getting at.  The current behaviour is what it is - the focused
Component (if there is one) gets keyboard events, but that may not be ideal in a multi-window
> I agree that it would be more intuitive if Pivot took into account the active OS window
in desktop apps with multiple Displays.  I'm not sure if there is anything else to consider
(full screen mode, undecorated/chromeless windows, always-on-top windows, if there are any
OSes with different concepts of active windows), but it sounds like a reasonable feature request.
> Ultimately I suppose it just boils down to a simple change in the algorithm used to forward
keyboard events?  Rather than blindly forwarding to the focused Component, it would filter
out the events where the focused Component is not in the active AWT Window.
> At the moment, I think the focus model is the same for applets & desktop apps, but
applets will only ever have one display when desktop apps might have many.
> I think that sending unhandled keyboard events to the Pivot Display based on the active
AWT Window should probably be a separate change request.
> Chris
> On 9 March 2011 08:26, Bill van Melle <bill.van.melle@gmail.com> wrote:
> Can you elaborate and explain what behaviour you would expect to see?  What seems broken?
> It seems like a principle of window-system focus rules that if I have one OS-window focused
(all nicely indicated by a highlighted title bar or whatever mechanism the desktop manager
uses), that keystrokes I type should not be taken as input to some other OS-window.  I don't
think most users' internal model of a window system goes any deeper than that (of realizing
that different windows are collectively owned by some app and might have a single notion internally
of focus), and I can't think offhand of any application I've run into that violated this principle.
> The behavior I'd want to see is that keystrokes go to a component in the focused OS-window,
or if there is no focused component therein, that they are sent to the key listener, if any,
of the Pivot Display that is hosted in that OS-window.
> Thanks for the suggestions about Display handling.  I'll look into whether that will
do the trick.

View raw message