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.
Summary: | Request for naming convention change in Shortcuts/ folder | ||
---|---|---|---|
Product: | platform | Reporter: | Jesse Glick <jglick> |
Component: | -- Other -- | Assignee: | issues@platform <issues> |
Status: | NEW --- | ||
Severity: | blocker | CC: | issues, jpokorsky, jtulach |
Priority: | P3 | Keywords: | ARCH |
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 14710, 17597, 17693, 18868, 104878, 135842 |
Description
Jesse Glick
2001-09-26 13:45:44 UTC
Target milestone -> 3.3.1. Target milestone -> 3.3.1. Target milestone -> 3.4 Target milestone -> 3.4 Target milestone -> 3.4 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. 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. |