This is a request for a review of the current naming scheme of
keyboard shortcut files, at least as they are written in the core
layer and as produced by the KB Shortcuts dialog. Currently I think
the expected format is: Shortcuts/C-F12[org-foo-Class].instance. This
is not ideal; e.g. OpenVMS may not correctly store filenames with 
in them. Suggest perhaps Shortcuts/C-F12.instance with
instanceClass=org.foo.Class. This should be compatible for modules as
the definition of a shortcut can remain unchanged: an action instance,
where the DataObject.name is the keyToString(KeyStroke). It may be
better long-term for upgrading user directories; i.e. if I have
Ctrl-F12 bound to something, that means Shortcuts/C-F12.instance
exists in my user dir, masking any other binding the IDE may
introduce. In contrast, the current scheme will behave poorly with
upgrades (can produce multiple bindings for the same key). Another
concern not solved by that, is that bindings introduced other than by
.instance will not properly override .instance bindings; for
example, Ant shortcuts are e.g. Shortcuts/C-F12.xml, where the XML
file is an Ant script run when Ctrl-F12 is pressed. Any core-supplied
keystroke Shortcuts/C-F12.instance would conflict with this. See
#14710 for example. We have a similar problem as we had with
xml/lookups/: we want a predictable filename for the instance to be
stored in, but a file extension must be possible for data loaders to
do their job; here it is a bit worse because it is common for
shortcuts to be overridden esp. on user install layer, whereas XML
public ID processors would not normally be overridden. Perhaps you
could adopt the convention (note this is still compatible, I think)
that Shortcuts/C-F12.shadow would be used, and would point to the
action (e.g. Actions/System/org-foo-Class.instance, or
Actions/Ant/some-shortcut.xml which would be created by the Ant
shortcut wizard). The DataObject.name is still C-F12 and the instance
is still correct, and overriding would work reliably because the file
extension is predictable. Modules or user directories continuing to
use the old convention would continue to have these shortcuts
recognized, though conflicts would be possible.
Target milestone -> 3.3.1.
Target milestone -> 3.4
Marek when you do 17693 please take also this one. Trung has added
couple of days to your plan for 17693.
Target milestone was changed from '3.4' to TBD.
Here is a slight alternative which I now like better: change the API
for finding shortcuts. Continue to recognize Shortcuts/$KEYSTROKE.*
for compatibility, but prefer Shortcuts/$KEYSTROKE/* (taking the first
in folder). I.e.: for any subfolders of Shortcuts/, take the folder
name as the key binding, and bind to the first javax.swing.Action
instance you find in that folder by using DataFolder.Children and
searching for InstanceCookie. This could be done easily with
FolderInstance, I think.
Modules could then install in their layers e.g.:
Easy enough. If another module tried to bind to CS-F12 as well, one
will win; the user could decide which by reordering the folder, or one
module could use relative ordering attrs to give the system a hint
which one to prefer in case of conflict. (Neat.)
The instances could be simple .instance files, complex scripts,
shadows, etc. according to taste; the API is kept simple.
From a user perspective, you could see the contents of Shortcuts/
displayed in Options somewhere (for example), and drag-and-drop stuff
into a shortcut folder, or create a new shortcut folder. To remove a
shortcut binding, just delete the folder, or just all of the files in it.
A different implementation technique with the same basic behavior
would be to use JNDI to find shortcuts, and let the core/naming module
do the work of mapping folders of instances to JNDI. (Core can provide
a special JNDI proxy for the existing Shortcuts/ folder as a special
case.) Permits the API to be even more generic and flexible, though
the user UI is still going to have to assume the shortcuts are stored
in a particular place in the system file system in order to provide
Passing to Dafe
I'm not sure if this is also covered by Hanz's work, please reassing back if I'm
I think the location of the folder changed, but the naming convention is still
Btw. in case more than one action is registered in the folder, then the system
could pick up the one that is right now enabled. This would solve problem of
two completely unrelated actions sharing (in different context) the same
jtulach's last comment refers to
But I think that is a quite different consideration related to the need for
multiple independent InputMap's. This issue was really about still having only
one action be bound to a given keystroke, just making it relatively easier to
deal with conflicts between modules.
Is this still valid or obsolete? I know virtually nothing about shortcuts management, passing to general category.
I don't know enough about shortcut handling in the new Options dialog to say whether this is still important. Insofar as
people still register shortcuts in the Shortcuts/ folder, it is still valid.