Request for review 7151821: [macosx] Mnemonic doesn't work in JTabbedPane
Anton V. Tarasov
anton.tarasov at oracle.com
Wed Mar 14 02:38:35 PDT 2012
On 13.03.2012 20:26, Leonid Romanov wrote:
> Thanks! I've played with javax/swing/JTabbedPane/4624207/bug4624207.java and there is an interesting thing about it: although mnemonics for switching between tabs don't work, setting focus to the "Name" text field via ctrl+alt+m works just fine. So, could it be that there is something broken about the way how JTabbedPane mnemonics are handled? I'm not an expert when it comes to mnemonics, but it seems to me that mnemonics use key codes, so they shouldn't be affected by key char value, right?
This is a good question.
A valid keyChar value is supposed to be delivered by KEY_TYPED event :
<<The getKeyChar method always returns a valid Unicode character or CHAR_UNDEFINED. Character input
is reported by KEY_TYPED events: KEY_PRESSED and KEY_RELEASED events are not necessarily associated
with character input. Therefore, the result of the getKeyChar method is guaranteed to be meaningful
only for KEY_TYPED events.>>
So, we shouldn't actually rely on keyChar in non KEY_TYPED events.
I also experimented with the test and found out that, for instance, ctrl+alt+Number mnemonic did
work for JTabbedPane. The reason is that such a key stroke produces a valid keyChar (Number). So
here's another question: what is the difference b/w ctrl+alt+Number and ctrl+alt+Letter in terms of
a keyChar? May the fix for 7134826 be the right place to look at
> On 13.03.2012, at 20:05, Alexandr Scherbatiy wrote:
>> 13.03.2012 18:35, Leonid Romanov пишет:
>>> Hit "Send" too early. Basically, what you are describing in 7151821 is exactly the way JDK 6 works. So, what is wrong with it? Does it break anything?
>> It is definitely a regression from the b225.
>> The key listener got a KeyEvent with the key char 'a' after pressing for example the Ctrl+Alt+a.
>> And it is expected that the key char should be 'a' in this case.
>> In the latest build the key char is not 'a' for a KeyEvent.
>> The test case with the KeyListener installed to the JPanel is described in the issue 7151821:
>> The Alt+Key combination is a system combination on Mac and can't be used for mnemonics.
>> It seems that the Mac OS X is not friendly to the Java mnemonics.
>> Here is some comments from the document:
>> Using mnemonics is discouraged in Mac OS X, because mnemonics violate the principles of Mac OS X Human Interface Guidelines. If you are developing a Java application for multiple platforms and some of those platforms recommend the use of mnemonics, just include a single setMnemonics() method that is conditionally called (based on the platform) when constructing your interface.
>> Note: Since the ALT_MASK modifier is the Option key in Mac OS X, Control-Alt masks set for Windows become Command-Option masks if you use getMenuShortcutKeyMask() in conjunction with ALT_MASK.
>> So the Ctrl+Alt+char used for the mnemonics on all tests instead of the Alt+char.
>>> On 13.03.2012, at 19:24, Leonid Romanov wrote:
>>>> What is the test case for this issue? What Control+alt+char is supposed to do?
>>>> On 13.03.2012, at 17:13, Alexander Scherbatiy wrote:
>>>>> Please review a fix for 7151821.
>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7151821/webrev.00/
>>>>> This is a fix for regression after switching using [event charactersIgnoringModifiers] string to [event characters] during the MACOSX_PORT-568 issue fixing:
>>>>> The characters string is null during Ctrl+Alt+Char mnemonic pressing.
>>>>> According to the NSEvent charactersIgnoringModifiers doc:
>>>>> This method returns the non-modifier key character pressed for dead keys, such as Option-e.
>>>>> For example, Option-e (no shift key) returns an “e" for this method, whereas the characters method returns an empty string.
>>>>> The fix uses the charactersIgnoringModifiers string for the keychar when the Ctrl+Alt mnemonic key combination is pressed.
More information about the macosx-port-dev