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: | Deprecate manifest node installation | ||
|---|---|---|---|
| Product: | platform | Reporter: | Jesse Glick <jglick> |
| Component: | Window System | Assignee: | David Simonek <dsimonek> |
| Status: | VERIFIED FIXED | ||
| Severity: | blocker | CC: | jrechtacek, jtulach, lkramolis, phrebejk |
| Priority: | P2 | Keywords: | API |
| Version: | 3.x | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Issue Type: | TASK | Exception Reporter: | |
| Bug Depends on: | 23634 | ||
| Bug Blocks: | 17815, 20517, 23399 | ||
|
Description
Jesse Glick
2002-01-19 15:07:47 UTC
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 ;-) |