> > Take a look at the attached app. > It opens 2 native OS windows, each containing 4 types of Pivot Windows > (none of which contain any focusable Components). > It uses a simple mechanism to forward unhandled keyboard events to the > active Pivot Window (if there is one) >
This seems like a clever solution. I'm not sure it quite works right, though. When I run your example, if I set the window system focus to the other display, without clicking inside one of the windows inside the display, it appears that Pivot's focus doesn't change -- Window.getActiveWindow is unchanged, and it still has its frame decorated as the focused window. Seems to me that Pivot's notion of the active window really ought to always be within the OS-focused display. When I played around with your example, substituting a focusable component (TextInput) for ImageView in one of the displays, or making the displays host a single, maximized window (my standard use case), I got even weirder behavior, such as input going to one subwindow even after clicking the frame title of a different subwindow or even the other display. See the attached revision of your App file.
PivotWindowFocusTestApp.java
Description: Binary data
