Project

General

Profile

Bug #4291

The main menu bar should not change based on the location of focus.

Added by David Welker over 10 years ago. Updated about 10 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
core
Target version:
Start date:
08/07/2009
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
4291

Description

Currently in Kepler, if you are editing a workflow, the menu bar has a rich set of commands. However, if you change focus and click on something else, say a Display actor window, the menu bar changes completely.

The menu bar should never change. If a change of focus leads to commands being no longer relevant, those commands should be grayed out instead of being removed.


Related issues

Blocked by Kepler - Bug #4286: Changes to the GUI before 2.0Resolved08/07/2009

History

#1 Updated by Christopher Brooks over 10 years ago

I believe this is a Mac OS X specific bug, so I'm changing the Hardware and OS.
I'm also lowering this in priority because the system still works with
this bug.

The bug can be restated as:
In many schools of UI design, it is considered to be "bad" if the menu choices
change. It is considered good design if menu choices are disabled instead
of removed. However, this rule is often violated.

In Kepler under Mac OS X, we now have one menu bar at the top, which
presumably follows the Mac design. However, on other platforms, each window
has its own menu bar. So, on other platforms, the graph editor, the Display
actor and the Plotter all have separate menu bars, but on the Mac, we
currently change the menu bar depending on the focus.

One possible solution would be to have the Display and Plotter disable
all non-applicable menu choices.

However, a larger issue is that we basically have a plug-in system where
the user adds functionality and we don't know what menus will be added as
the system is run and new functionality is loaded. So, an entirely static
set of menu choices is not really possible in a user extensible system.
Currently, the vergil graph viewer, the Display actor and the Plot actor all
use ptolemy.gui.Top, which provides some uniformity of menu choices.

I see this as quite a bit of work and out of scope for 2.0.0. It would
be faster to identify a Mac OS X UI compliant system and redevelop using
that system. Looking at how Netbeans and Eclipse RCP work might help here.

I agree that developing menu infrastructure that changed less might be nice,
but should we hold up 2.0.0 for this?

#2 Updated by Redmine Admin over 6 years ago

Original Bugzilla ID was 4291

Also available in: Atom PDF