[
https://issues.apache.org/jira/browse/PIVOT-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13068570#comment-13068570
]
Chris Bartlett commented on PIVOT-720:
--------------------------------------
Given Bill's example, I had been thinking of something along the lines of ...
A new method, Display#getActiveDisplay(), would return the Display considered
to be active in the eyes of the current OS/application.
The internals of it are very much up for discussion, but I was thinking that
Window#isActive() would probably be used by default, but this could be
overridden if required.
http://download.oracle.com/javase/6/docs/api/java/awt/Window.html#isActive()
In the case of an applet or a desktop application with only one Display, I
imagine that this would return the only Display.
In the case of a desktop application with multiple Displays, it would return
null unless exactly 1 Display was considered active.
(Alternatively a desktop application with multiple Displays might return the
first Display if 0 or >1 were considered active.)
// Pseudo-code for dispatch of keyboard events
// Get the AWT event & prepare as a 'Pivot keyboard event'
keyStrokeEvent = ...
// The active Display is the initial target
Display activeDisplay = Display.getActiveDisplay();
Component destinationComponent = activeDisplay;
// Try to find a more specific target within the active Display
// Would this ever be null?
if (activeDisplay != null) {
// Use the active Pivot Window?
Window activeWindow = Window.getActiveWindow();
if (activeWindow != null && activeWindow.getDisplay() == activeDisplay) {
destinationComponent = activeWindow;
}
// Use the focused Pivot Component?
Component focusedComponent = Component.getFocusedComponent();
if (focusedComponent != null && focusedComponent.getDisplay() ==
activeDisplay) {
destinationComponent = focusedComponent;
}
}
// Dispatch the keyStrokeEvent for processing
boolean consumed = false;
if (destinationComponent != null) {
consumed = dispatchKeyStrokeEvent(keyStrokeEvent, destinationComponent);
}
// Note that this differs from the current implementation, and is more of a wish
// than a requirement (and it should probably live in it's own JIRA ticket)
// The UnprocessedKeyHandler would become a 'UnconsumedKeyStrokeHandler' rather
// than a 'ApplicationHasNoFocusedComponentsKeyStrokeHandler'
if (!consumed && unprocessedKeyHandler != null) {
dispatchKeyStrokeEvent(keyStrokeEvent, unprocessedKeyHandler);
}
A couple of notes
- The above pseudo-code is just intended to demonstrates the logic of a
dispatch algorithm designed to offer some flexibility over blindly sending
events to the focused Component.
- The decision to restrict keystrokes to the active Display/native Window,
might potentially be set via a Pivot start-up property.
> Want keystrokes to go to the native OS window that has focus
> ------------------------------------------------------------
>
> Key: PIVOT-720
> URL: https://issues.apache.org/jira/browse/PIVOT-720
> Project: Pivot
> Issue Type: Improvement
> Components: wtk
> Affects Versions: 2.0
> Reporter: Bill van Melle
> Fix For: 2.1
>
>
> If you use DesktopApplicationContext.createDisplay to create a new OS window,
> and you want to handle keystrokes sent to that window, the only way your key
> listener will get called is if there is a focused Pivot component in that
> window. But not all interesting windows contain a focusable component, and
> even when they do, there are often good reasons not to focus a particular
> component by default. Meanwhile, if Pivot's notion of the currently focused
> component is in a different OS window, keystrokes will go there, even though
> it's not the window that appears to the user to have focus (as judged by the
> native window system focus decoration), which is counterintuitive.
> There is extensive discussion at
> http://apache-pivot-users.399431.n3.nabble.com/KeyListeners-on-ImageView-td2600622.html
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
