This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
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.: <folder name="Shortcuts"> <folder name="CS-F12"> <file name="org-nb-foo-MyAction.instance"/> </folder> </folder> 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 GUI editing.
Passing to Dafe
I'm not sure if this is also covered by Hanz's work, please reassing back if I'm wrong.
I think the location of the folder changed, but the naming convention is still the same. 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 shortcut.
jtulach's last comment refers to http://openide.netbeans.org/source/browse/openide/arch/arch-openide-actions.xml?r1=1.35.2.22&r2=1.35.2.23 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.