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.
When trying to write action which isn't subclass of SystemAction (and is not a singleton) I encountered problem with shortcuts. The shortcuts registry (NbKeymap) creates its own instance of action, but this action is never used to find the shortcut for the instances which are in menu or toolbar. (I implemented the equals/hashCode methods appropriately, but they were never called) IMO the problem is that the o.o.awt.Actions doesn't look into the Keymap to find the shortcut for action, it relies that the action is singleton and that the same instance is used in the menu, toolbar, shortcut registry. I'll attach a patch which tries to fix the problem. Unfortunately it doesn't work reliably for toolbars which seem to be initialized sooner that the NbKeymap :-(.
Created attachment 10113 [details] patch for o.o.awt.Actions
AFAIK there is nothing wrong with o.o.a.Actions. NbKeymap sets ACCELERATOR_KEY in the Action to the proper value it is loading Shortcuts/. (See NbKeymapTest.) Therefore o.o.a.Actions does not need to look at the global Keymap. Just because your Action is not a SystemAction is probably not an excuse for it to have multiple instances in the same VM. There should be just one instance at a time; there might be >1 instance of a given class, but they should be considered distinct actions. Note that you should be able to enforce this by writing e.g.: Actions/Whatever/MyAction.instance: instanceOf=javax.swing.Action instanceClass=org.nb.MyAction Menu/Whatever/MyAction.shadow -> Actions/Whatever/MyAction.instance Shortcuts/S-F6.shadow -> Actions/Whatever/MyAction.instance Cf.: http://openide.netbeans.org/proposals/actions/design.html#ref issue #15926 Probably in the future we would like to make registration of actions cleaner, so the Registry API should support (1) Registering actions in /Actions subfolders, e.g. "/Actions/Category/MyAction" would be a valid subcontext or binding or whatever. (2) Registering links from other places, e.g. /Menu/Foo/MyAction would link to /Actions/Category/MyAction. (3) Ordering, so that /Menu/Foo could be ordered; and also /Shortcuts/S-F6/MyAction -> /Actions/Category/MyAction would produce a shortcut S-F6 for MyAction (and if there were >1 binding in /Shortcuts/S-F6, all but the first one are ignored). David, please think about whether this means that the Registry needs to support links at the client API level, or whether it is sufficient to support them at the registration syntax level (e.g. in the current XML: *.shadow and the originalFile attr).
OK. Thanx.
I afraid that registration level only is not enough. If I copy&pasted some action from action pool into a menu then just the link should be stored in the Registry and not the copy of instance. In the version of Registry API I just posted to nbdev there is an ObjectRef class in the API which is just a simple reference to an object - it holds context and binding name. If we wrote a convertor which would create from .shadow file instance of ObjectRef and vice versa (binding ObjectRef into Context would result in .shadow file) do you think that would be sufficient? At the moment I quite like this idea as it is very simple, but I might be missing some more complicated scenarios. Of course current ObjectRef would have to be slightly modified to for example allow to reference only context without the binding name specified - current link to a folder.
What is the problem? How do you mean, that NbKeymap creates its own action instance? I also don't understand that patch. Does it mean that there is a state where action.getValue(ACCELERATOR_KEY) gets null, but from global keymap for that 'action' instance you get non-null? If yes, I guess it is a bug, and possible fix should prevent such a state. Anyway those patch I don't want to apply.
Well, my action is not singleton (doesn't extend SystemAction), in order to have it in main menu, toolbar and associate the shortcut with it I need to register three .instance files on three places in my module's XML layer. This of course causes three instances if my action to be created - one for main menu bar, second for toolbar and third used by NbKeymap. I think the solution (DataShadow links) suggested by Jesse will work for me, but it seems to me more like a workaround then proper solution. In fact my scenario is following: - I need to expose some action in API and don't want to expose the whole class so I have the factory method - the action is parametrized and thus it can't be singleton - I don't know where the client will use my action (in main menu, somewhere in popup menu, in toolbar, will create shortuct, etc.) - I am able to decide somehow which instances of my action do the 'same thing' and implement corretly equals, hashCode methods Is this scenario supported by new Actions API? If not, what's the expected usage of this API?
IMHO using a DataShadow here is the correct solution, not a workaround; there should not be >1 instance of the Action, even if they are equals(), unless you implement them to really behave the same by e.g. overriding putValue to store that value in *all* equal instances of the action (so that NbKeymap will effectively store the correct shortcut in all the clones).
IMHO this is WONTFIX. Vita is free to use a .instance file (or whatever) for the Actions/ pool and .shadow's elsewhere, and then the accelerators ought to work. I don't see any particular reason to complicate the Actions API by requiring that the infrastructure deal with equal but not identical instances w.r.t. accelerators; no other Swing models have this kind of behavior.
Marking as wontfix. Individual action instance should take care of "sharing the shortcut" if they want to do such strange thing. I think now, there shouldn't be shown shortcuts on that individual actions. If you use that shortcut it is performed the "globa" instance, not the contextual one. Check some other app's. They don't provide shortcuts on such contextual action instances (unless the shortcut is really connected to that concrete action instance). It seems, showing shortcuts in NB is just a consequence of using of SystemAction's (as singletons). Anyway see also issue #36792, there is an argument how it should be made in NB.
Forgot to mark.
verified