Review request for 7142565 - [macosx] Many special keys processed twice in text fields
Anthony Petrov
anthony.petrov at oracle.com
Wed Feb 8 07:10:08 PST 2012
Looks perfect. Thank you!
--
best regards,
Anthony
On 2/8/2012 8:07 PM, Anton V. Tarasov wrote:
> On 2/8/12 1:35 PM, Anthony Petrov wrote:
>> Hi Anton,
>>
>> The fix looks fine.
>>
>> Unless there are consistency considerations, you could move the
>> declaration of the static variable into the method's body to localize
>> the logic around this not-retained object pointer (and avoid adding
>> any comments about that, too.) I'll leave this up to you and other
>> reviewers.
> I put it to the top anticipating comments like you got for your fix
> (which I looked at). But ok, let's narrow the scope.
>
> http://cr.openjdk.java.net/~ant/7142565/webrev.1/
>
> Thanks,
> Anton.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 2/8/2012 1:49 PM, Anton V. Tarasov wrote:
>>> Hello,
>>>
>>> Please review a fix for 7142565.
>>>
>>> webrev: http://cr.openjdk.java.net/~ant/7142565/webrev.0/
>>>
>>> Key-equivalent events (typically with modifiers, but not only) are
>>> delivered to NSWindow with
>>> performKeyEquivalent: The latter always returns NO (to let NSWindow
>>> process system key events like
>>> Cmd+Q). According to the spec "if a key-equivalent is not recognized,
>>> NSWindow sends it as an
>>> NSKeyDown event to the first responder". (However, it doesn't send
>>> NSKeyDown for Control-key
>>> events.)
>>>
>>> Instead of inspecting a key-equivalent event to determine if it
>>> should be propagated further or not,
>>> another simple workaround is suggested. It's to store a pointer to
>>> the latest processed key event in
>>> AWTView and compare the current event to the previous one. In case
>>> the event objects are the same,
>>> ignore the second (current) one.
>>>
>>> Thanks,
>>> Anton.
>>>
>>>
>
More information about the macosx-port-dev
mailing list