Ticket #1182 (closed task: fixed)
Opened 2012-05-16T10:31:19-05:00
Last modified 2012-06-26T10:56:32-05:00
Decide on how to implement menus
| Reported by: | bdezonia | Owned by: | bdezonia |
|---|---|---|---|
| Priority: | major | Milestone: |
|
| Component: | Core | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | curtis, dscho | Blocked By: | #1160, #1161 |
| Blocking: | #1162 |
Description
Currently menus are supported differently by platform. On the Mac they are duplicated (one per display). On Windows there is only one. The duplication causes performance problems for some commands (like Stack To Images).
Anyhow we may want to move to a model where there is a default menu and additional menus for contexts that need them (such as the script editor). We would need a facility for swapping menus when the active window changed. And we also would want that action to update some of the values in the default menu if needed (such as marking image type in the image menu and active window in the window menu).
However we may want to support duplication of menus across all platforms (via an option setting) so that there is one menu per window regardless of platform. If so we need an efficient implementation.
There are multiple other menu tickets that are related to these problems and are marked as blockers here.
Change History
comment:2 Changed 2012-05-17T13:37:26-05:00 by curtis
- Type changed from feature to task
- Blocking 1162 added
comment:3 Changed 2012-06-11T13:36:40-05:00 by bdezonia
After some discussion with Curtis we have a plan. We will default to a single shared application menu (using the approach of the fix-menus branch). Other windows/frames can override the active menu with their own. Thus in the short term we won't have to worry about menu synching. The entries and check boxes for the window menu and the image type will exist in one place and will be updated by window change events.
The current code in the fix-menus branch is a kludge to prove one single menu bar could be supported on the mac. It waits to create a single menubar after the legacy service has loaded so that the shadow menu is fully populated before the one menu bar is created. We need a more robust approach. The plan is to have the service initialization code emit a AllServicesInitializedEvent. Then the UI can wait on that event before creating the menubar.
By going this direction we need to keep the unaddressed menu synching tickets around pushing them to later milestones so that the ideas are not lost. We may not implement them soon but a day may come where they will be more relevant.
comment:4 Changed 2012-06-26T10:56:32-05:00 by bdezonia
- Status changed from new to closed
- Resolution set to fixed
We've gone forward with a single menu bar approach.