Actions: specifying mnemonics in property files

  3 posts   Feedicon  
Replies: 2 - Last Post: March 24, 2010 22:22
by: kwutzke
showing 1 - 3 of 3
 
Posted: March 24, 2010 14:27 by kwutzke
Hello all,

AFAIK there are three ways to specify mnemonics in property files

1. Using inline ampersands:

To specify actions in property files "the SAF way" is to use strings like

saveAs.Action.text = Save &As

right?

Is the ampersand a good choice, e.g. for languages like Chinese etc.? Shouldn't it have been a character that every language has? I doubt any such thing exists, correct me if I'm wrong. If so, shouldn't the mnemonic be a simple integer instead, as in the JavaSE Action API?

2. Separate character:

The alternative to inline specification of mnemonic using the ampersand is to use

saveAs.Action.text = Save As
saveAs.Action.mnemonic = A

but that has disadvantages, too. What if the action text contains multiple mnemonic characters and I want to highlight the second, third, or whatever occurrence?

What if the character doesn't exist? Okay, I see this is similar to an index out of bounds, so specifying...

3. Separate integer (as index):

... has the out of bounds problem as well. The clear advantage of 3. is language-independent specification, because (and again please correct me) the ampersand is not part of every language. (?)

Now that there are three ways to specify mnemonics, which one is the best?

Karsten
 
Posted: March 24, 2010 20:16 by Eric Heumann
Hello Karsten,

My short answer to your question is: I think the first choice (using the &) is the most convenient, and easiest to alter if you change the text value (name) of the Action.

For the sake of SAF documentation, I'll go a little deeper...

The Ampersand: &

According to Wikipedia, the ampersand is in the Latin family of characters (the & symbol is basically a cursive 'e' and cursive 't' on top of one another, because "et" in Latin means "and", thus the origin of the ampersand), and therefore I'm assuming its use in non-Latin alphabets (e.g. Cyrillic, Greek, Chinese, etc) to be less common, as you indicated.

However, Java, like the languages that influenced it, originated in the United States and thus uses English keywords and Latin characters (since English uses the Latin alphabet). This is why the ampersand is inherently present in Java...
Boolean logic:
true && false

Bitwise Operations:
0x2222 & 0x000F

Given this presence in the language itself, I'd assume that anyone programming in the Java language would somehow have access to the ampersand character.

Alternative: The Underscore: _

If the ampersand isn't going to fly (I apologize; I'm from the United States and have never even seen anything except a US QWERTY keyboard), there is an alternative! You can use an underscore instead of an ampersand. It will do the same thing. If your action text is "Open File" and you want the O in Open to be the mnemonic, using "&Open File" or "_Open File" as the Action text will accomplish the correct mnemonic placement.

The Code

Here is the relavent code in SAF:
        // TBD: mnemonic marker char should be an application resource
        int markerIndex = mnemonicMarkerIndex(markedText, '&');
        if (markerIndex == -1) {
            markerIndex = mnemonicMarkerIndex(markedText, '_');
        }

Therefore, the & takes precedence over the underscore.

As seen in the comment, apparently at one point in time there was some discussion about allowing the programmer using SAF to declare which character should be used to indicate mnemonics. This would alleviate this whole issue, since instead of using an ampersand or underscore, you could use whatever the heck you wanted. Unfortunately, this apparently has not been implemented yet, and I have seen no discussion about the issue.

Note that if there is a space after a & or _, or if a & or _ is surrounded by single quotes (e.g. '&' or '_'), the character will be included in the text and not used as a mnemonic declaration. An Action text of "Open File & Data" will appear as written, and will have no mnemonic unless option 2 or 3 are employed.

Use of Action.mnemonic and Action.displayedMnemonicIndex

The only reason for using options 2 or 3 instead of the first would be if you wanted to have the displayed mnemonic index to be different than the actual mnemonic value. If your Action's text was "Open File", you could set Action.mnemonic = F and then set Action.displayedMnemonicIndex = 0, and then in a JMenuItem, the F would be underlined, but hitting Alt-O would click it. I could not think of a good reason to do this... in fact it seem like a horrible idea because your GUI would not be consistent with commands, but who knows. In any case, it's possible this way.

 
Posted: March 24, 2010 22:22 by kwutzke
First off, thanks for replying in such an elaborate manner, I found the SAF code to be especially helpful.

I believe, the underscore is the much more intuitive character to specify mnemonics. The two reasons: first, the underscore much better resembles what users actually see on the screen: an underlined character. Second, the underscore is much, much more uncommon in visual (action) texts/names. Considering the ampersand like just another character would make more sense to me.

In any case, I'm beginning to like the idea of specifying mnemonics inline. From a usability point of view, having differences between the actual and display mnemonic doesn't make sense to me. Has anyone ever needed them?

The reason for all my asking ultimately is this: I want to create a public repository for common action translations, exactly what can be found on the Swing Labs named "Common Translations":

http://wiki.java.net/bin/view/Javadesktop/SwingLabsWackyWiki#Common_Translations

The only thing I have to dig though now are accelerators, because Macs have different modifier keys: ctrl s doesn't exist there IMO.

Karsten
Replies: 2 - Last Post: March 24, 2010 22:22
by: kwutzke
  • Mysql
  • Glassfish
  • Jruby
  • Rails
  • Nblogo
Terms of Use; Privacy Policy;
© 2010, Oracle Corporation and/or its affiliates
(revision 20120518.3c65429)
 
 
Close
loading
Please Confirm
Close