I made a new action using apisupport and added it to the Build category, i.e.
Actions/Build/ in the layer. When running the module I was surprised to find
that the Keymap panel of the Options dialog did not offer this action in the
After some investigation I found that the Keymap panel actually looks in
OptionsDialog/Actions/ for all its global actions and that it has a copy of all
actions registered from other modules.
Clearly this is not maintainable in the long run. Please cease to use
OptionsDialog/Actions/ and just use plain Actions/. If there are UI problems
with the arrangement of items in Actions/ then we should fix them in the proper
place - the defining modules.
I am not 100% sure, Jesse. There are some issues with plain Actions folder:
- We have one actions folder only, but there can be more views for actions -
currently we have Toolbar customizer & Shortcuts customizer. And we do not want
to show exactly same tree in both of them.
- All actions should be registerred is Actions folder, but we do not want to
show all of them in Shortcuts Customizer. Thats why I have
"OptionsDialog/Actions/Hidden" folder for such actions.
- Some actions should have different names in Menu / Toolbar / Pop-up menu /
Shortcut Customizer. For example, user can understand what does it mean if there
is some action called "Files" in pop-up menu on Java file - "Select in / Files".
But if you have the same action in shotrcuts customizer, you may want to have it
in folder "Views" and its name can be different than simple "Files"... Just example.
Just thinking, the same action can have little bit different presentation in
different UI components - different size of icon, name, tooltip... Thats why I
think that we should have one "Actions" folder (without any subfolders), and
than some other folders for different UI components. And this folders should
contian some "filterring" stuff for actions. What do you think about that?
"currently we have Toolbar customizer & Shortcuts customizer. And we do not want
to show exactly same tree in both of them" - no? why not?
"All actions should be registered in Actions folder, but we do not want to
show all of them in Shortcuts Customizer" - why? IMHO all actions should can be
invoked in a general place (either context-insensitive, or using a context which
could be provided from any number of components) should be listed in Actions/;
and only those actions. Actions such as o.n.m.image.ZoomInAction should simply
be removed from the global pool, I think, or there could be an Actions/Hidden/
folder that hides them from *all* parts of the GUI.
I understand that some things like o.n.m.project.ui.RecentProjects are simply
placeholders for menu presenters and are not true actions that can be invoked,
which is why I suggested on nbdev that there be a different interface for them
than Action, but Yarda said no - perhaps he will reconsider, or perhaps we can
find a more compatible compromise such as getProperty("phony") -> Boolean.TRUE
meaning that the action should never be used as is - and is thus not suitable
for a keymap customizer, and only suitable for a menu customizer if it
implements Presenter.Menu, etc.
Re. different names for the same action - getProperty(Action.NAME) should always
return a fixed, context-insensitive name suitable for displaying e.g. in the
Shortcuts customizer. A particular menu, popup, or toolbar presenter may choose
to provide a different label suitable to its context, but that is not the
responsibility of the settings GUI.
I believe this and related issues must be solved thoroughly and cleanly for 5.1
in the context of an actions overhaul. It is unacceptable for us to not be able
to even document precisely what you need to do to add a first-class menu item to
the IDE! I understand there were time pressures for 5.0 that prevented a proper
solution, so 5.0 IDE module developers are just going to have to suffer a bit.
Please ask for waiver if it's not going to be fixed for 5.0. Thanks.
Who is responsible for this?
Reassigning to core/options.
Implemented in editor/options
Radku, so can I close this as fixed?
I think by "implemented in editor/options" Radek meant that the responsible implementation code resides in
editor/options, not that the problem has been fixed.
Jesse, what you propose to do?
I have a fix, which reads actions directly from Actions (not OptionsDialog/Actions)
Problem is, that Actions have more actions and more categories than original OptionsDialog/Actions. And moreover some
actions are in wrong folder. For instance "Run Main Project" action should be in category "Run" (according to original
OptionsDialog/Actions), but in fact this action is under Actions/Projects folder. The same problem with "Debug Main
Project", which should be under "Run" but it is under "Debug". Should I commit my fix and file bugs against various modules?
I think it would make sense to have responsible modules adjust their Actions/** contents to match whatever UI spec we
have. (Do we have one?)
Main outstanding question that I see is about pseudo-actions which are only good for a menu presenter. (Described
earlier - search for getProperty("phony"), though "placeholder" might be a more descriptive property name.) Probably in
the short term these could just be removed from the Actions/ pool and instantiated directly in Menu/ (i.e. without a
*.shadow); only impact would be that anyone still using the Menu customizer in Advanced Options (which I presume will
still be visible in 6.0) would not be able to readd this action from the File menu if they deleted it. I think this is a
Or it might work to simply make e.g. RecentProjects implement Presenter.Menu but not implement Action, and ensure that
the keymap customizer ignores non-Action instances. For classes which implement ContextAwareAction but whose
actionPerformed is meaningless (i.e. cannot be invoked with a context), I think there is no reason to put them in
Actions/ to begin with - they cannot usefully be bound to accelerators, global menu items, or toolbar buttons. These are
only really useful in context menus, to which they can be registered directly.
I'm sure various details will come up which will need to be addressed somehow - I hope without requiring any new APIs,
or significant changes in action registration style from the pre-5.0 state.
Let me summarize the situation:
There are 2 kind of actions in the IDE: Editor Actions (actions registered through Editor APIs) and "Layer Actions"
(actions registered through layer.xml)
Both kind of actions are now unified (and mirrored) through OptionsDialog/Actions.
I propose to
1. Remove mirroring of "Layer Actions" (editor/options module)
2. Read actions directly from Actions folder (core/actions module)
3. Keep OptionsDialog/Actions/ folder for Editor Actions
4. File bugs against modules, that they don't have their actions under proper folders in layer.xml
For #3, it is a strange location, but perhaps harmless. Otherwise sounds good. Does anyone else involved in the 5.0+
handling of action bindings have an opinion on this?
Checking in editor/options/src/org/netbeans/modules/options/editor/mf-layer.xml;
/cvs/editor/options/src/org/netbeans/modules/options/editor/mf-layer.xml,v <-- mf-layer.xml
new revision: 1.44; previous revision: 1.43
Checking in core/options/keymap/src/org/netbeans/modules/options/keymap/LayersBridge.java;
/cvs/core/options/keymap/src/org/netbeans/modules/options/keymap/LayersBridge.java,v <-- LayersBridge.java
new revision: 1.5; previous revision: 1.4
Josef Pavlicek agreed to review categories to identify wrong placement of actions. Then we can file issues against
I think this may need to be revisited. According to layers.txt  there are still a fair number of actions registered here, but not all editor actions are there (e.g. reindent-line, in Editors/Actions/), and some actions there do not look like editor actions (e.g. the whole Subversion category). Anyway the (relatively) new declarative registration of editor actions may change the evaluation; presumably we either want this annotation processor to insert entries in OptionsDialog/Actions/ or we do not want that folder to exist at all.
Adding dep on bug #145314 for notes from comment #2 but I guess this is orthogonal.
It will be revisited after #204452