-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
-
6
-
x86
-
windows_xp
A DESCRIPTION OF THE REQUEST :
This follows up comments on Scott Violet's weblog:
http://weblogs.java.net/blog/zixle/archive/2005/11/the_usefulness.html#11363
With javax.swing.Action, the ACCELERATOR_KEY is used to indicate a keystroke, such as CTRL+G or F3, that can be used to invoke the action directly, instead of clicking on the component with the mouse. Currently, this property is only used when the action is added to a JMenu in a JFrame's JMenuBar, but it is ignored when the action is associated with a JButton or a JToolBar.
In contrast, the MNEMONIC_KEY property is used in all of the above components, however this is not always satisfactory (see the justification for this RFE, below).
It would be practical in many use cases for the ACCELERATOR_KEY key binding to be used even if not present in the menu bar.
JUSTIFICATION :
The current behaviour seems to assume that actions will be used only in the main JFrame of an application, and that such an application will have a JMenuBar containing all the actions one might wish to "accelerate".
For other actions, say an "OK" or "Cancel" button, it is reasonable to bind a MNEMONIC_KEY (say "O" and "C" in this case), for which a visual cue (say underlining the letters "O" and "C" in the button's text). However, there are cases (such as toolbars and tool palettes) where buttons may contain an image and no text, so such a visual cue may not be possible, and furthermore, it may be more practical to use bindings such as F5 for a toolbar "Refresh" icon (the choice of F5 being suggested for conformity with Windows application guidelines, see http://www.javalobby.org/forums/thread.jspa?messageID=91885413� for some links to such guidelines for different desktops), and not some mnemonic combination: ALT+F5 is an unusual combination, and even if the button had its text displayed, how would a mnemonic for ALT+F5 be rendered...?
I often need to create JDialogs and there too, it's pratical to use actions instead of manually wiring up ActionListeners and so on, as well as manually creating "input map" and "action map" key bindings (to manually implement accelerators). Dialogs generally don't have menu bars, but often do have quite a lot of actions in non-trivial applications, so this lack of support for ACCELERATOR_KEY is unfortunate and makes making accessible and practical applications more tedious.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
If an action is added to a JToolBar or JButton, and if that action defines a value for the ACCELERATOR_KEY property, then it should be bound.
ACTUAL -
If an action is added to a JToolBar or JButton, and if that action defines a value for the ACCELERATOR_KEY property, it is ignored.
This isn't a problem if the action is also present in a JMenuBar, but this isn't always the case.
CUSTOMER SUBMITTED WORKAROUND :
Various tedious solutions exist, generally with cut-and-paste solutions:
* when creating an action, after adding it to a JButton or JToolBar, also add it to inputMaps and actionMaps.
* subclass AbstractAction and provide the logic to create the keybindings when supplied with a reference to the component that uses the action (there may be more than one)
This follows up comments on Scott Violet's weblog:
http://weblogs.java.net/blog/zixle/archive/2005/11/the_usefulness.html#11363
With javax.swing.Action, the ACCELERATOR_KEY is used to indicate a keystroke, such as CTRL+G or F3, that can be used to invoke the action directly, instead of clicking on the component with the mouse. Currently, this property is only used when the action is added to a JMenu in a JFrame's JMenuBar, but it is ignored when the action is associated with a JButton or a JToolBar.
In contrast, the MNEMONIC_KEY property is used in all of the above components, however this is not always satisfactory (see the justification for this RFE, below).
It would be practical in many use cases for the ACCELERATOR_KEY key binding to be used even if not present in the menu bar.
JUSTIFICATION :
The current behaviour seems to assume that actions will be used only in the main JFrame of an application, and that such an application will have a JMenuBar containing all the actions one might wish to "accelerate".
For other actions, say an "OK" or "Cancel" button, it is reasonable to bind a MNEMONIC_KEY (say "O" and "C" in this case), for which a visual cue (say underlining the letters "O" and "C" in the button's text). However, there are cases (such as toolbars and tool palettes) where buttons may contain an image and no text, so such a visual cue may not be possible, and furthermore, it may be more practical to use bindings such as F5 for a toolbar "Refresh" icon (the choice of F5 being suggested for conformity with Windows application guidelines, see http://www.javalobby.org/forums/thread.jspa?messageID=91885413� for some links to such guidelines for different desktops), and not some mnemonic combination: ALT+F5 is an unusual combination, and even if the button had its text displayed, how would a mnemonic for ALT+F5 be rendered...?
I often need to create JDialogs and there too, it's pratical to use actions instead of manually wiring up ActionListeners and so on, as well as manually creating "input map" and "action map" key bindings (to manually implement accelerators). Dialogs generally don't have menu bars, but often do have quite a lot of actions in non-trivial applications, so this lack of support for ACCELERATOR_KEY is unfortunate and makes making accessible and practical applications more tedious.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
If an action is added to a JToolBar or JButton, and if that action defines a value for the ACCELERATOR_KEY property, then it should be bound.
ACTUAL -
If an action is added to a JToolBar or JButton, and if that action defines a value for the ACCELERATOR_KEY property, it is ignored.
This isn't a problem if the action is also present in a JMenuBar, but this isn't always the case.
CUSTOMER SUBMITTED WORKAROUND :
Various tedious solutions exist, generally with cut-and-paste solutions:
* when creating an action, after adding it to a JButton or JToolBar, also add it to inputMaps and actionMaps.
* subclass AbstractAction and provide the logic to create the keybindings when supplied with a reference to the component that uses the action (there may be more than one)