[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: Accelerator in System MenuBar
From:       Kevin Rushforth <kevin.rushforth () oracle ! com>
Date:       2019-03-20 23:41:23
Message-ID: 6e9d701d-3e86-32ea-ed66-00f8abf4ef39 () oracle ! com
[Download RAW message or body]

This seems a reasonable approach to me.

-- Kevin


On 3/19/2019 6:38 AM, Dean Wookey wrote:
> Returning a boolean in View.notifyKey may also be useful for the windows
> bug: https://bugs.openjdk.java.net/browse/JDK-8089986 where, regardless of
> whether the accelerator is missing or not, there is a beeping sound.
> Ideally there would be a beep only if the event isn't consumed.
>
> Dean
>
> On Tue, Mar 19, 2019 at 3:23 PM Johan Vos <johan.vos@gluonhq.com> wrote:
>
>> Related to https://github.com/javafxports/openjdk-jfx/issues/370:
>>
>> The issue appears on Mac, with a system menubar. When the scene contains
>> e.g. a TextField (which has a CMD-V keymapping), and a menuitem has been
>> assigned a CMD-V accelerator, the latter should not be invoked when the
>> action is performed on the TextField.
>>
>> When the menuitem is in a normal JavaFX MenuBar, this works fine as the
>> event handling marks the event as consumed when the TextField processes it,
>> hence it won't continue to the accelerators.
>> However, when the menuitem is in a system menubar, the native
>> performKeyEquivalent function first calls the the Java layer
>> (View.notifyKey) and then unconditionally passes the event so that the
>> system can process it.
>> My thinking is that this can be avoided by having the View.notifyKey
>> returning a boolean, which is true when the Java layer consumed the event,
>> in which case the native performKeyEquivalent should return YES.
>>
>> Before I create a PR on this, I wonder if there are other ideas for doing
>> this?
>>
>> - Johan
>>

[prev in list] [next in list] [prev in thread] [next in thread]