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.
For 3.4 we should probably replace manifest installation of nodes with layers - for completeness, and because it is very important to people working with NB as a platform (branding...). I suggest something like this: 1. Some folder, perhaps UI/Explorer/, should be dedicated to storing the desired contents of the main explorer. This is different from the Windows/.../explorer/ mode, for that stores what the user currently has visible and docked. This folder should be manipulated only by modules and provide the permanent Explorer contents. 1a. Maybe it can be a FolderInstance. Anyway it should recognize Node or Node.Handle instances and create roots for them. It should also recognize subfolders recursively, in which case a simple node (not FolderNode) with name, display name, and icon taken from the folder should be created, and subnodes recursively. 1b. Optionally, recognize instances of TopComponent directly under UI/Explorer/ (not subfolders), if this is easy to implement. It might not be - need to look at what the window system will do to store state of such components. 1c. NbMainExplorer.openRoots (called from OpenExplorerAction) should open the contents of UI/Explorer/. 2. Deprecate installation of nodes from manifest. When a module with node sections is installed, use FixedFileSystem to create corresponding Node .instance's under UI/Explorer/ (root), UI/Explorer/Runtime/ (core-supplied folder; environment), or UI/Services/ (session). 3. Switch the core and all standard modules to use layers rather than manifest node sections.
Good plan.
Looks a lot like window system issue. So Dafe, please evaluate this. I think that it would be really cool to have it as part of platform release, but I can imagine your objections...
Yes, I have some objections... - (minor) Windows/.../explorer/ mode stores also closed comps, not only opened My main doubt is if we need this functionality at all - I would remove it completely, modules now can specify explorer tabs using Windows/.../... layers. In fact, project module, javadoc module do so now. From the UI point of view, users commonly don't understand why View/Explorer action is so different that it opens tabs like "Javadoc", "projects" or even some components of modules we don't know about. What is the advantage of specialized UI/Explorer folder? I think I didn't catch the point.
Well if the current behavior of View | Explorer - to reopen closed tabs - is not in fact desirable, then things are much simpler: we just need to make sure that node sections in NbInstaller autocreate a proper top component in the Explorer mode, for compatibility, using FixedFileSystem. If we simplify View | Explorer to not reopen closed tabs, and a user closes one of these tabs, how does the user get it back?
ui question, and as of most ui questions, I'm not sure :-) My opinion is that there should be View/Filesystems, View/Javadoc etc. But of course this may not be good from UI expert look, I don't know. Anyway, even with current ui design, I would say that module which wants to place something into explorer should do exactly the same steps as module trying to place window somewhere else: - define Windows/.../Explorer/myComp - provide action to view/(and/or hide) the component Am I missing something?
Makes sense to me - probably want to check on nbui to confirm that this sounds OK. (Javadoc tab may go away anyway, so we would have View | {Filesystems, Runtime, Project} in a typical build.) Note that we might run out of Ctrl-<digit> keyboard shortcuts. If this is OK, then yes modules can do this stuff themselves with the current API, and for backwards compatibility NbInstaller could provide (1) the component definition for the explorer tab, (2) an action (instance of javax.swing.Action, not SystemAction) in the View menu to (re)-open it.
working...
implemented in main trunk. - manifest node installation marked as deprecated in documentation - new way of putting instance files into UI/Runtime and UI/Services introduced and fully documented (hepofully fully :-) - for backward compatibility, NbInstaller transforms manifest nodes into *.instance entries. - Environment node changed to work with regular FolderChildren. - nobody is using old deprecated way of installing Root nodes and Session nodes in standard netbeans distribution now. - root nodes backward compatibility needs UI opinions, created special issue http://www.netbeans.org/issues/show_bug.cgi?id=22758
so, verified
Dafe, I don't see this change listed in openide/api/doc/changes/apichanges.xml. Could you add it please?
Also Libor on dev@openide requests that the deprecation message in the log file point to this issue or to the documentation describing what to replace the node section with.
Libor pls. check Modules API. All you need to do, I think, is drop a .instance file in UI/Runtime/ folder.
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.
Above, "receipt" should read "instructions". Sorry ;-)