JDK-8091173 : It would be helpful if one could listen to keyboard events even though the control is not focused
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: scenegraph
  • Affected Version: 8
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2013-10-09
  • Updated: 2018-09-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Description
There are a number of use cases where one needs to listen to keyboard events and does not necessarily have the control under focus. For instance games are a good example.
-----
There was a thread on javafx Mailing list where Artem Ananiev and Richard Bair both agreed something like this is useful:


                On 10/7/2013 2:40 AM, Pedro Duque Vieira wrote:
                Hi,

                I have the following use case:
                When the user presses shift and the mouse is hover the
                chart component the
                cursor must change to an open hand cursor signaling to
                the user that the
                chart is ready for a panning action.
                The problem is that for this to be possible I want the
                chart to be able to
                listen to keyboard events even when it doesn't have focus.

                I think this is not possible and I wonder why. Swing was
                the same, you
                could only listen to keyboard events if the control had
                focus. Is this a
                technical limitation? If there is no technical
                limitation I think it would
                be better to remove this restriction, I think it is
                limiting and the above
                scenario is a good use case to show that.


            On Oct 7, 2013, at 3:56 AM, Artem Ananiev
            <artem.ananiev@oracle.com <mailto:artem.ananiev@oracle.com>>
            wrote:

            This is not a technical limitation, it's just the way how
            it's supposed to work. All the key events are dispatched to
            the component in focus, this is what input focus is.

            Scenario you described should be easier to implement in FX
            than in Swing. In AWT/Swing, input events are dispatched to
            a single component, while FX is much more flexible. All the
            events are delivered to a Scene first, then dispatched to
            the focused component (or component under mouse, for mouse
            events), then bubbled up back to the Scene. What you need is
            to register a custom event filter for the scene and listen
            to all the key events.

            See Scene.addEventFilter() and Scene.addEventHandler() for
            details.

            Thanks,

            Artem

        On 10/7/2013 6:53 PM, Richard Bair wrote:

        That being said, this seems like a very common use case, and I
        wonder if there is something more we could do (in the longer
        term, short term do as Artem suggests)

On Mon, Oct 7, 2013 at 6:03 PM, Artem Ananiev <artem.ananiev@oracle.com> wrote:

One of the options is to provide API to query for keyboard state at any arbitrary moment, whether particular key is pressed or not. Even if we only support locking keys (Caps, Num, Scroll, Kana) and control keys (Shift, Control, Command, Alt), it will be of great value. Game developers will be happy to have such API for all the keys, including navigation and letter ones.

Thanks,

Artem


Comments
This feature will likely require support from SceneGraph and Quantum. This bug is about SceneGraph part.
10-10-2013