[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-ui-dev] Proposal - Context and pulldown menus affecting resources in Navigator view
|
Hi Lucinio,
Thanks for the input. This is exactly what we are hoping to see.
Please see DS>
"Lucinio Santos"
<santosg@xxxxxxxxxx> To: platform-ui-dev@xxxxxxxxxxx
Sent by: cc:
platform-ui-dev-admin@e Subject: [platform-ui-dev] Proposal - Context and
clipse.org pulldown menus affecting resources in Navigator view
11/30/01 10:37 AM
Please respond to
platform-ui-dev
The current organization and distribution of menu items among context and
pulldown menus involving resources in Navigator View is somewhat
unbalanced. Consequently the context menus are too long and seemingly
disorganized, while certain pulldown menus (Project) are underutilized,
thus keeping inconspicuous important items (e.g., Project properties)
The following proposal addresses this issue:
1- Reorganize the context menus: Better Grouping (according to semantics
and usage) and separators (see summary at the end).
2- Remove "Open Perspective" from the context menu. It doesn't belong
here since this action is not "tied" to the selected resource/object
(e.g., the opened perspective doesn't select the current resource
automatically). This is already in the "Perspective" pulldown.
Although it could be argued that having it in the context menu provides
a "shortcut", given the large number of items, we have to be selective
and only place items in the context menu that pertain to the selected
object/resource... to keep the context menu to a manageable size.
DS> Actually, the Open Perspective action in the navigator and the packages
view IS tied to the selection. If you select a folder, and invoke Open
Perspective, the visible items within the new perspective are confined to
the contents of the folder. This is an intentional way of scoping what you
see.
3) Remove "Go To". As above. This is just a navigational shortcut we
can do without (arguably) . These GoTo operations are provided already
in the Navigator toolbar (it's already close to a selected object, so
there is not a lot of "mouse travel" gain anyway.
DS> This may be reasonable. I might also suggest that Go To should be in
the pulldown menu for consistency.
3- Open Project and Close Project are complementary and mutually
exclusive. One one is enabled the other one is disabled. There is no
need to have entries for both. There should be a single "Open Project"
or "Close Project" depending on the current state of the project.
DS> Good idea.
4 -The Project pulldown is underutilized. Currently contains a single
item: Rebuild All. Some of the options exclusively presented in Context
menus are quite important (Validate, Edit Deployment Descriptor, and
Properties) and we should surface in the menu bar to make them more
visible. Thus...
The Project pulldown should include all the items currently present in
context menu for a selected project. If the resource selected is a
File or (non-project) folder instead of a project, the Project
pulldown would be populated with the items present in the context menu
of the project to which the selected File or folder belongs to.
DS> I know there is some discussion that the name of the Project menu
should actually be changed to Workbench, or something similar, as this menu
doesn't pertain to the actual project, but pertains to everything in the
workbench, whether it is a project, projects, or stuff outside of the
resource workspace. Some of your choices for the menu contents are
interesting. Validate and Edit Deployment Descriptor are definitely WSAD
actions. Would you contribute them using an action set?
... Except the following (context menu items) which would be placed
under other pulldowns (instead of in the Projects pulldown)
- Clipboard items (Cut, Copy, Paste, Delete) would be placed in
the Edit The following items currently present in context menu
would be removed. This items are already in the Edit pulldown
- Team (Edit pulldown)
- Replace with (Edit Pulldown)
- Compare with (Edit Pulldown)
- Go into (File pulldown)
DS> The team oriented items are very resource centric. If you're in the
help perspective, would these items still be visible? If so, how would you
resolve the resources which should be used for the team actions?
DS> My current thinking is that Eclipse is very context menu oriented. In
some ways this is a reflection of the goals, to be an open, extensable
platform for tools. This makes it very difficult to place resource
specific actions in the menus. Instead, we have chosen to adopt a few
actions in the window menu which are generic (save, close, cut, copy,
paste) and universal. The inclusion of domain specific actions in the
window may be misdirected.
Context menu Pulldown Menu
New... File (already there)
OpenProject/Close Project Project (this only shows for
projects. One entry for both)
Open File (this only shows for projects. Already
there)
Refresh from Local Project (if context menu of a Project)
or File (if context menu of a File)
Go into File
----------------------------
Copy Edit (already there)
Move Edit (already there)
Rename Edit (already there)
Delete Edit (already there)
------------------------------
Run on Server Project
Restart Project ((this only shows for projects)
_________________
Run Validation Project (this only shows for projects)
Validate HTML syntax Tools (this only shows for files. This is
already in the Tools pulldown)
------------------------------
Team Edit
Compare with Edit
Replace with Edit
_________________
Properties Project (if context menu of a Project) or
File (if context menu of a File)
DS> In the table above, it looks like many of the actions in the Project
menu will only appear if a project is selected. Is my interpretation
correct, or would they be enabled / disabled instead? If the selection
controls their appearance, do you think the user will be disoriented when
the window menu changes dynamically, depending on the selection. One of
the advantages now is that the window menu and toolbar are predictable, and
the context menu contains all of the actions for an object.
DS> Your choice of the edit menu for team items is interesting. I actually
view these as file operations. If you put them in the edit menu, wouldn't
the user be confused if they are actively editing a document? Or do you
suggest that these actions come and go, depending on the active part within
the window. We considered an approach like this, but decided it would
cause too much menu and toolbar flash. Toolbar change in itself can lead
to relayout of the entire window. I know one of our partners strongly
believes that the edit menu should always target the active editor,
regardless of the focus.
The principles here are:
- Place all objects pertaining to a selected object in its
context menu... meaningfully organized
- Placed generic items having to do with projects in the Projects
pulldown (in addition to the context menu)
- Place generic items having to do with files i the File pulldown
(in addition to the context menu)
- Place "edit" type items in the Edit pulldown whether the object
is a file or a project...
Lucinio Santos
Web Tools Human-Computer Interaction
Phone: (919) 543-4813 (tie: 3-4813) - Fax: (919)
254-4147
Internet: santosg@xxxxxxxxxx
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev