⚠

NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #992 (new defect)

Opened 2012-02-22T11:37:31-06:00

Last modified 2013-01-22T15:40:32-06:00

Allow classes other than Displays to maintain menu bar

Reported by: bdezonia Owned by: curtis
Priority: major Milestone: imagej2-unscheduled
Component: UI Framework Version:
Severity: serious Keywords:
Cc: Blocked By: #1591
Blocking: #1630

Description

On the mac the menu bar is reestablished every time a display is created that grabs the focus. Some interactive plugins (such as SwingOverlayManager) need to make sure the basic menu bar is available.

Right now I've made a tweak to AbstractSwingUI that makes createMenuBar() public rather than protected. And SwingOverlayManager does some ugly casting to register a valid menu bar with its own frame.

Ideally we'd change the updating of the menu bar such that all frames (and not just displays) can maintain menu bar functionality. This might necessitate generating a new kind of event (INeedAMenuBarEvent) rather than listening for DisplayCreatedEvent.

Change History

comment:1 Changed 2012-02-22T12:33:55-06:00 by curtis

Two thoughts:

  1. The display framework is shifting such that DisplayEvent and WinEvent are crucially distinct (but related) things. The menu bars really go along with window events, not display events, so the UIService should take care of manufacturing new menu bars to go along with new windows, regardless of whether each window is a display.
  1. In the case of SwingOverlayManager, we could actually have a UI-agnostic OverlayManager that *does* implement Display<Overlay>, since that's exactly what it is. Then the Swing UI would need a SwingOverlayManagerPanel/SwingOverlayManagerWindow implementation that takes care of actually representing that onscreen, providing buttons, etc. But the API for adding/removing overlays and so on would live at the UI-agnostic level. All of this would be a nice use case for Displays to prove their flexibility as intended, and would also make it easier for alternative UIs to implement an overlay manager component.

comment:2 Changed 2012-05-09T13:08:10-05:00 by curtis

  • Blocking 1162 added

comment:3 Changed 2012-07-12T11:10:21-05:00 by curtis

  • Blocking 1291 added; 1162 removed
  • Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta4

We now use a single menu bar on all platforms. On Mac OS X, we use the "default Application menu bar" feature. Unfortunately, the default Application menu bar keyboard shortcuts do not work—at all. We work around this using the AcceleratorHandler tool, but that only works for Displays, and not windows of other types. So this problem still requires further thought.

comment:4 Changed 2012-08-03T10:21:06-05:00 by curtis

  • Blocking 1356 added

comment:5 Changed 2012-08-03T10:22:25-05:00 by curtis

  • Blocking 1291 removed

(In #1291) Pushing some menuing tickets to 2.0.0-beta5; see #1356.

comment:6 Changed 2012-09-06T14:32:30-05:00 by curtis

  • Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0-beta5

comment:7 Changed 2012-12-06T11:40:26-06:00 by bdezonia

  • Blocking 1591 added

comment:8 Changed 2012-12-06T11:42:49-06:00 by bdezonia

  • Blocking 1591 removed

comment:9 Changed 2012-12-06T11:42:59-06:00 by bdezonia

  • Blocked By 1591 added

comment:10 Changed 2013-01-22T15:40:32-06:00 by bdezonia

  • Blocking 1630 added; 1356 removed
  • Milestone changed from imagej2-b7-ndim-data to imagej2-unscheduled