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.

Bug 22758 - replace View/Explorer with View/Filesystems, View/Runtime etc
Summary: replace View/Explorer with View/Filesystems, View/Runtime etc
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Nodes (show other bugs)
Version: 3.x
Hardware: PC All
: P2 blocker (vote)
Assignee: Peter Zavadsky
URL:
Keywords: UI
Depends on: 28048
Blocks: 17815 19443 20517
  Show dependency tree
 
Reported: 2002-04-24 18:55 UTC by David Simonek
Modified: 2008-12-22 20:41 UTC (History)
7 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Simonek 2002-04-24 18:55:30 UTC
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.
Comment 1 Marek Grummich 2002-07-22 11:27:41 UTC
Set target milestone to TBD
Comment 2 Marek Grummich 2002-07-22 11:29:18 UTC
Set target milestone to TBD
Comment 3 David Simonek 2002-07-26 12:36:05 UTC
needs UI comments and decision. passing to ui group, ccing others.
Comment 4 Jesse Glick 2002-08-19 00:47:24 UTC
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.
Comment 5 Peter Zavadsky 2002-08-29 10:37:05 UTC
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.


Comment 6 Jesse Glick 2002-10-15 18:00:15 UTC
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.
Comment 7 jrojcek 2002-10-16 10:10:02 UTC
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.
Comment 8 David Simonek 2002-10-16 10:26:43 UTC
Jano, mnemonics and icons, please?
Comment 9 Jesse Glick 2002-10-16 10:37:47 UTC
Important for issue #19443 & UI of projects module.
Comment 10 jrojcek 2002-10-16 10:46:46 UTC
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.
Comment 11 David Simonek 2002-10-16 11:18:38 UTC
For Workplace view too?
Comment 12 jrojcek 2002-10-16 11:27:03 UTC
As far as I know final icons for projects are not ready yet so for now
please use old project tab icon.
Comment 13 Jesse Glick 2002-10-17 15:58:47 UTC
I think this is now FIXED? Actually #28048 should have marked a
duplicate of this and this FIXED, I guess...
Comment 14 Peter Zavadsky 2002-10-17 16:44:34 UTC
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.
Comment 15 Peter Zavadsky 2002-10-21 09:13:45 UTC
Assigning to Jano. Please specify, how the menu should look like
(separators, position according to other items, ordering).
Comment 16 jrojcek 2002-10-21 10:02:04 UTC
It has been specified, please read my previous comment.
Comment 17 Peter Zavadsky 2002-10-21 13:33:33 UTC
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).
Comment 18 Jesse Glick 2002-10-21 16:24:52 UTC
"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.
Comment 19 Peter Zavadsky 2002-10-21 18:07:13 UTC
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?

Comment 20 David Simonek 2002-10-22 08:08:24 UTC
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.
Comment 21 Peter Zavadsky 2002-10-22 08:58:13 UTC
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).
Comment 22 Peter Zavadsky 2002-10-22 14:49:44 UTC
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. )
Comment 23 Jesse Glick 2002-10-22 15:42:13 UTC
Well, enhance FFS if you need to, I guess.
Comment 24 Peter Zavadsky 2002-10-22 15:59:51 UTC
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.
Comment 25 rmatous 2002-10-22 17:58:10 UTC
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.
Comment 26 Jesse Glick 2002-10-22 19:26:10 UTC
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);
}
Comment 27 rmatous 2002-10-23 09:56:03 UTC
Jesse is naturally right. I was blind to trivial impl. of attributes
in FixedFileSystem. Sorry, for bothering you with not  relevant problems. 
Comment 28 Peter Zavadsky 2002-10-23 17:30:57 UTC
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.