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.

Bug 15926 - Request for naming convention change in Shortcuts/ folder
Summary: Request for naming convention change in Shortcuts/ folder
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: issues@platform
URL:
Keywords: ARCH
Depends on:
Blocks: 14710 17597 17693 18868 104878 135842
  Show dependency tree
 
Reported: 2001-09-26 13:45 UTC by Jesse Glick
Modified: 2009-01-06 14:09 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2001-09-26 13:45:44 UTC
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.
Comment 1 Jan Chalupa 2001-11-27 11:52:09 UTC
Target milestone -> 3.3.1.
Comment 2 Jan Chalupa 2001-11-27 11:56:00 UTC
Target milestone -> 3.3.1.
Comment 3 Jan Chalupa 2002-01-11 14:02:31 UTC
Target milestone -> 3.4
Comment 4 Jan Chalupa 2002-01-11 14:05:58 UTC
Target milestone -> 3.4
Comment 5 Jan Chalupa 2002-01-11 14:07:27 UTC
Target milestone -> 3.4
Comment 6 Jan Chalupa 2002-01-11 14:10:41 UTC
Target milestone -> 3.4
Comment 7 David Strupl 2002-02-26 09:30:08 UTC
Marek when you do 17693 please take also this one. Trung has added
couple of days to your plan for 17693.
Comment 8 Marek Grummich 2002-07-22 08:30:52 UTC
Target milestone was changed from '3.4' to TBD.
Comment 9 Marek Grummich 2002-07-22 08:35:18 UTC
Target milestone was changed from '3.4' to TBD.
Comment 10 Jesse Glick 2002-07-30 17:35:40 UTC
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.
Comment 11 mslama 2002-08-05 17:37:00 UTC
Passing to Dafe
Comment 12 David Simonek 2005-04-28 16:49:45 UTC
I'm not sure if this is also covered by Hanz's work, please reassing back if I'm
wrong.
Comment 13 Jaroslav Tulach 2005-12-21 12:42:17 UTC
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. 
Comment 14 Jesse Glick 2005-12-21 21:54:50 UTC
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.
Comment 15 David Simonek 2008-10-16 15:58:58 UTC
Is this still valid or obsolete? I know virtually nothing about shortcuts management, passing to general category.
Comment 16 Jesse Glick 2008-10-17 23:16:26 UTC
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.