[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[platform-ui-dev] Proposal - Context and pulldown menus affecting resources in Navigator view
|
Nick and David,
Thanks for your prompt and detailed responses. Good points. It looks
like you had these issues in mind. Just a couple of follow-up comments in
response to yours:
- Projects menu.
- The Projects pulldown would always be there even if something other
than a project is selected. If a file or (non-project) folder instead
of a project is selected, the Project pulldown would be populated with
the items the project to which the selected File or folder belongs to.
So there would always be an enabled "Project" pulldown, although it's
true that some of its content may vary depending on the nature of the
project (e.g., "Export WAR" in a Web project would be "Export EAR" in
an EAR project).
- I can see the value of a "Workbench" pulldown. But I'd consider this
to place workbench wide items ("Preferences" would be the perfect
candidate), but it seems that there would still be a need to surface
project specific actions currently semi-hidden in context menus. This
could be the function of the Projects menu (serving a function similar
to the old "Selected" pulldown... but more restricted... only/always
project related functions).
By the way, in this regard, apologies since many of the choices
were WSAD specific actions, but are those kinds of actions that would
be important to surface... by simply duplicating the contents of the
context menu of the selected project (or project under which the
selected resource is contained) in a "Projects" pulldown... whatever
those are (platform and/or component specific). This probably could be
keep the openness/extensibility of the platform.
- Dynamism of the pulldown menus. Yes, the Edit pulldown is already
quite dynamic. Not sure we can get away from it (the contents of "Edit"
depending on what is being edit). I can see that the contents should not
depend on which View is active, but it seems ok that the contents are
sensitive to the nature of the resource.
Also, I wonder about the effects of having a separate "Java","Web",
etc pulldowns. It seems they could end up being a long mix bag of Edit
and other items... probably a very long menu though not fully
comprehensive (i.e., in the case of the Web we could have things like
"Edit style" for the resource being edited, but... would it also have a
"Properties" item for the project? After all these are "web"related"
choices). Bottom line... I'm not sure having separate "Java", "Web",
"EJB" pulldowns will solve this. Also, would all these be there all the
time or would they be sensitive to the active view (back to the
"dynamism" the solution was trying to avoid).
Thanks again,
Lucinio Santos
Web Tools Human-Computer Interaction
Phone: (919) 543-4813 (tie: 3-4813) - Fax: (919) 254-4147
Internet: santosg@xxxxxxxxxx
"David Springgay/OTT/OTI" <David_Springgay@xxxxxxx>@eclipse.org on
11/30/2001 11:59:58 AM
Please respond to platform-ui-dev@xxxxxxxxxxx
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
To: platform-ui-dev@xxxxxxxxxxx
cc:
Subject: 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
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev