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.
Some IDE users don't understand well meaning of action View/Explorer, which opens several components (like projects tab, runtime tab, filesystem tab). Common situation is that after closing "Runtime" tab, they don't know how to bring it back. Suggestion: replace View/Explorer with individual View/Filesystems etc. actions, which will easier to understand. from implementation point of view, this will allow us to significantly simplify code and behaviour in NbMainExplorer class, also maintaining backward compatibility for root nodes will be much easier. Look into 19609 issue for implementation details.
Set target milestone to TBD
needs UI comments and decision. passing to ui group, ccing others.
Ought to simplify core platformization as well. I would like to remove the Runtime tab from the platform (keep only in core/ide module). Unfortunately this does not work correctly at the moment, since the core tabs in the Explorer are hardcoded and cannot be split up.
Dafe's instructions from the issue #19609 (it should help): Receipt of how to move manifest nodes to layers: Even more types of module-provided settings can in 3.4 be registered via XML layer rather than in manifest. Layers are more flexible, brandable. The basic definition of how settings in layers work is given in the Services API. Here is list of types of nodes that might formerly have been present in a manifest which should be moved: * Environment nodes. Nodes of type Environment should be placed in the UI/Runtime/ folder using *.instance syntax, simply specifying class of the node in question. * Session nodes. Nodes of type Session should be placed in the UI/Services/ folder, again using *.instance syntax. * Root nodes. Nodes of type Root should be placed in the Windows/Components/ folder using *.settings syntax, defining org.openide.explorer.ExplorerPanel type of component. Use ability of *.settings file to specify creator method to asociate explorer panel with your root node. Consult Winsys API, xml layers section for details.
Any progress on this? As part of issue #19443, the Workplace tab will probably disappear from the UI even when the projects module is not installed... there is no particularly good way to tell if there is a ProjectCookie any more, since it is deprecated. It will probably be important to have this implemented soon. Please consider this a P2 for 4.0. It also blocks issue #20517 which is a compatibility defect.
Okay, seems we should do it for 4.0. It should look as follows: * Instead of View|Explorer menu item three menu items would be shown in IDE - View|Workplace, View|Filesystems, View|Runtime * Only View|Workplace should have a shortcut Ctrl-2 * Ordering of items: Properties Workplace Source Editor ... Javadoc Index Search Runtime Filesystems * All three Views should open by default in center of the Explorer in this order - Workplace, Filesystems, Runtime * If user docks View to another Mode then it should be remembered when closing the View and open in same mode when opening the View Please note that ordering and shortcut assignment can change. I am not sure who should implement this, passing to Marek.
Jano, mnemonics and icons, please?
Important for issue #19443 & UI of projects module.
Mnemonics: Workplace - l Filesystems - m Runtime - t Please use the icons that are displayed in tabs of the Views. Dirk, this issue affects UI of projects. I hope it is okay to do it.
For Workplace view too?
As far as I know final icons for projects are not ready yet so for now please use old project tab icon.
I think this is now FIXED? Actually #28048 should have marked a duplicate of this and this FIXED, I guess...
Actually I've left there the explorer action and added the for individual views. There is slight problem with separators. Anyway, it needs UI eyes to look at it and sum it up how it should look like. (See in tomorrow build). Leaving open until then.
Assigning to Jano. Please specify, how the menu should look like (separators, position according to other items, ordering).
It has been specified, please read my previous comment.
I hope Workplace is supposed to be the new projects tab, right? Cause the old workplace tab doesn't exist anymore (you have seen it when uninstalled projects module). And where should be positioned the rest of items: javadoc + filesys + runtime? At the bottom, after all of others? Also note that the javadoc is not present now by default, so it is not specified in ui. Such a tab is then constructed just from its root node. I mean if there are more such tabs constructed this way, its menu items appear together. So there is a question if such item should precede the default ones, i.e.filesystems and runtime? Also I need to know whether some separators are needed or not. (There is a slight problem to force JInlineMenu to not use them, like it always does).
"I hope Workplace is supposed to be the new projects tab, right?" - AFAIK projects module should supply its own tab, contents TBD, and core should not supply one. "There is a slight problem to force JInlineMenu to not use them, like it always does." - who is using JInlineMenu and why? If you are thinking of making compat-mode manifest root installation add to a list of nodes handled by one JInlineMenu-presented system action, please consider instead adding one Menu/View/*.instance for each manifest root section, instanceof javax.swing.Action and instanceof org.openide.util.actions.Presenter.{Menu,Toolbar}. FixedFileSystem can add this instance, just like it will add the right window system XML files. There can be a single action class, instances parametrized (methodvalue) with the root node class name.
Workplace is the new project tab. It's me with JInlineMenu. Yes for the known tabs (filesys, runtime, projects aka workplace) I've put there the actions. But I thought, there has to be some way to show also the components in view menu of root nodes from other older modules. How can I avoid the JInlineMenu(its presenter) in that case?
Peter, it's wise to do it exactly like Jesse suggested. Read his comments to this issue and also to issue #19609, they're fairly complete IMO.
I was just behind the point what Jesse suggested. But I think I got it finally. I'll do it that way. (To issue #19609: I know about that, and there is no necessity to put the root nodes into layer now).
Hm, there seems to be a problem. There is not possible to add methodvalue attribute via FixedFileSystem (using FixedFileSystem.Instance.writeAttribute("instanceCreate", java.lang.reflect.Method); just serialized the Method object. )
Well, enhance FFS if you need to, I guess.
I was talking about it with Radek and he's got some idea, how to be able to put there the desired methodvalue. He will explain it.
methodValue is problem, that I must face very often. It`s convenient method how to declaratively define value of attribute. But there isn`t possible to create such attributes dynamicaly. Because methodValue is not attribute at all, but definition how to create such attribute. Problem is that we want to have attributes such flexible, but we have not appropriate API: getAttribute and setAttribute are not sufficient enough. This issue is next problem. We already have problem with copying, invoking methodValue from MultiFileObject. Well, I`m able to fix this issue. Classes Method and Constructor from java.lang.reflect can be considered as methodValue and newValue. Then setAttribute ("methodValue:attrName", method) will create methodValue attribute. And getAttribute ("attrName") will invoke method to get Object and getAttribute ("methodValue:attrName") will return java.lang.reflect.Method. But this can`t be guaranteed on all filesystems, because of insuficient API.
Re. Radek's comment: all true, but not relevant for this issue I think. FFS can control how it implements getAttribute, and can use any technique it likes to let clients of FFS specify attributes. For example, an overload of FFS.Instance.writeAttribute could accept an AttributeCreator (inner interface of FFS) instead of Object: public interface AttributeCreator { public Object createValue(FixedFileSystem thisFS, String thisFilePath, String thisAttr); }
Jesse is naturally right. I was blind to trivial impl. of attributes in FixedFileSystem. Sorry, for bothering you with not relevant problems.
Fixed in [trunk] core/src/org/netbeans/core/actions/ExplorerRootsViewAction.java delete core/src/org/netbeans/core/modules/NbInstaller.java 1.53 core/src/org/netbeans/core/modules/NodeSectionTranslator.java 1.2 core/src/org/netbeans/core/projects/FixedFileSystem.java 1.9 core/src/org/netbeans/core/EnvironmentNode.java 1.36 core/src/org/netbeans/core/NbMainExplorer.java 1.106 core/src/org/netbeans/core/NbPlaces.java 1.64 core/ui/src/org/netbeans/core/ui/resources/layer.xml 1.27 javadoc/src/org/netbeans/modules/javadoc/resources/mf-layer.xml 1.40 projects/src/org/netbeans/modules/projects/resources/projects-layer.xml 1.32 Used the Jesse's suggestion with FFS. The old roots translated to UI/Roots.