Bug #4291


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

Added by David Welker over 14 years ago. Updated over 14 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


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.0ResolvedDavid Welker08/07/2009

Actions #1

Updated by Christopher Brooks over 14 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?

Actions #2

Updated by Redmine Admin almost 11 years ago

Original Bugzilla ID was 4291


Also available in: Atom PDF