These were changed intentionally to provide the proper symbols for
menu shortcuts in Swing for in-window menu bars. Instead of using
the word "Meta" or "Command" we actually now return the unicode
symbol that the system menu bar shows.
Unfortunately, there did not appear to be a reasonable injection
point between the AWT toolkit properties and the Swing menu
system...and the fallout is that it makes debugging modifier keys
from Terminal more difficult. The tradeoff was basically between a
user-visible bug, and a behavior only developers would see.
Any suggestions how to provide the key symbols in Swing, and
maintain the existing semantics of KeyEvent.getKeyModifiersText()
and KeyEvent.getKeyText() would be appreciated.
My understanding of the contract of getKeyText() is that it returns
a human-readable textual description of a keycode. I would first
suggest putting getKeyText() back the way it was, as the current
implementation breaks that. This is not, as you characterize it, a
tradeoff between a user-visible bug and one only developers would
see -- it is a broken API which I discovered because it broke my app
in a very user-visible way (the text displayed for their selected
keys turned from "Left Arrow" to "?").
That said... how to get it so OS-X can have access to the pretty
menu-key characters in the particular font where they're displayed?
Why couldn't you use a derivative method? What you have is a
special-case need for Apple-OS, so why not make a special-case
class, AppleKeyEvent (extends KeyEvent) that has the override
getKeyText() behaviour you want, without altering established
behaviour. If *I* wanted to produce special-case output for
getKeyText(), and I didn't have the ability to alter the world of
millions of other people by changing Java itself, that's what I'd
have to do. :)
If you put the string returned into a JTextField or do a
Graphics.drawString(), you will see the expected keyboard modifier
symbol. The only reason you saw "?" is because the text encoding of
your terminal window did not take the bytes of that unicode character
and translate it into a glyph you could read.
Also, KeyEvent.getKeyText() is a static method. Creating an Apple-
specific subclass won't help. We try to make minimal code changes to
the generic shared code we receive from Sun, and in this instance,
changing the .properties file that contained this text seemed like the
lowest impact way to do this. From all of our testing, when these
strings are used in a Java application, they do show up as the
expected keyboard modifier symbols.
If this is a significant show-stopping bug for you, please do file it
at http://bugreporter.apple.com. Please also note how it impacts your
customers, if relevant. As always, we are looking to improve the user
experience of Java on Mac OS X, and will try to find a better (and
maintainable) solution to this issue.
Mike Swingler
Java Frameworks Engineer
Apple Inc.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
