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. G 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 scenario. > > 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 <[email protected]> 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. >
