Bug 19609 - Deprecate manifest node installation
Deprecate manifest node installation
Status: VERIFIED FIXED
Product: platform
Classification: Unclassified
Component: Window System
3.x
PC Linux
: P2 (vote)
: 6.x
Assigned To: David Simonek
issues@platform
: API
Depends on: 23634
Blocks: 17815 20517 23399
  Show dependency treegraph
 
Reported: 2002-01-19 15:07 UTC by Jesse Glick
Modified: 2008-12-23 09:53 UTC (History)
4 users (show)

See Also:
Issue Type: TASK
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2002-01-19 15:07:47 UTC
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.
Comment 1 Jaroslav Tulach 2002-01-28 09:41:59 UTC
Good plan.
Comment 2 Jaroslav Tulach 2002-02-19 13:20:16 UTC
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...
Comment 3 David Simonek 2002-02-19 13:39:08 UTC
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.

Comment 4 Jesse Glick 2002-02-20 12:55:10 UTC
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?
Comment 5 David Simonek 2002-02-20 13:30:31 UTC
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?

Comment 6 Jesse Glick 2002-02-20 15:08:21 UTC
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.
Comment 7 David Simonek 2002-04-23 13:27:49 UTC
working...
Comment 8 David Simonek 2002-04-24 18:56:16 UTC
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
Comment 9 Jan Zajicek 2002-04-26 16:01:34 UTC
so, verified
Comment 10 Jesse Glick 2002-05-08 20:50:39 UTC
Dafe, I don't see this change listed in
openide/api/doc/changes/apichanges.xml. Could you add it please?
Comment 11 Jesse Glick 2002-05-10 17:50:11 UTC
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.
Comment 12 Jesse Glick 2002-05-10 17:51:02 UTC
Libor pls. check Modules API. All you need to do, I think, is drop a
.instance file in UI/Runtime/ folder.
Comment 13 David Simonek 2002-06-26 16:02:50 UTC
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.
Comment 14 David Simonek 2002-06-26 17:42:54 UTC
Above, "receipt" should read "instructions". Sorry ;-)


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo