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: | OptionsDialog/Actions/ should be removed and just Actions/ used | ||
---|---|---|---|
Product: | editor | Reporter: | Jesse Glick <jglick> |
Component: | Options | Assignee: | Milutin Kristofic <mkristofic> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | josefpavlicek, jtulach, mmetelka |
Priority: | P4 | Keywords: | ARCH |
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 145314 | ||
Bug Blocks: | 70280 |
Description
Jesse Glick
2006-01-11 20:01:20 UTC
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 corner case. 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 OK? 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 done 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 done Josef Pavlicek agreed to review categories to identify wrong placement of actions. Then we can file issues against individual modules. I think this may need to be revisited. According to layers.txt [1] 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. [1] http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastSuccessfulBuild/artifact/nbbuild/build/generated/layers.txt It will be revisited after #204452 This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss |