Note: please ignore the fix-menus branch. It was an incomplete implementation. The latest implementation is coming soon but needs a little debugging and currently lives in the double-plugin-launch branch.
On Mon, Jun 11, 2012 at 2:14 PM, Curtis Rueden <[email protected]> wrote: > Hi everyone, > > Today Barry and I had a brief meeting about the ImageJ2 menuing system. > (For a brief description of how it works, I posted a write-up on the > ImageJ2 site at: http://developer.imagej.net/menuing-system). > > There are currently three issues with it: > > 1) Correctness. There are currently bugs syncing multiple copies of a menu > bar linked to the same ShadowMenu, as well as with checkbox menu items; see > http://trac.imagej.net/ticket/1162 for details. > > 2) Performance. Currently, on Mac OS X, we maintain one copy of the menus > (i.e., one JMenuBar) per UI window. Constructing these copies is slow > enough that there is a noticeable delay when a new image window pops up. We > have a potential solution using the Application default menu bar (see > http://trac.imagej.net/ticket/1161) on the fix-menus branch, which avoids > making these copies. > > 3) Capabilities. The current philosophy is that each menu root exists only > once with all of its state, including which menu items are checked, grayed > out, etc. This could be a problem in certain circumstances, if the menu is > supposed to reflect a different context per image, per script editor > window, etc. For example, if the Image > Type > 8-bit menu item is supposed > to be checked for an 8-bit image, but the 16-bit menu item should be > checked for a 16-bit image, only one of those items will *really* be > checked at any given time. Something (in this case, the TypeChangeService) > must react to the active image being changed, updating the selection state > for the modules in the Image > Type menu, and then *all* copies of the menu > change over accordingly. For non-top-level menu items, the user is > blissfully ignorant of this process, but they would notice if e.g. a > top-level menu item needed to be enabled or disabled based on the current > context. > > Barry & I agreed that solving issue #2 above is good enough for beta3, > especially since it "papers over" the main issues with #1. That is, by > avoiding clones of the menu bar, it matters less whether syncing between > copies of the menu is working completely correctly—because we won't ever > have copies of the menu to sync. But at some point, we should reconsider > the issues mentioned in #3 above, and decide on whether the current > approach is sufficient for everyone's needs. Two good candidates for > testing the limits of the menuing system are the script editor, and context > (i.e., right-click) menus. > > Regards, > Curtis > > > _______________________________________________ > ImageJ-devel mailing list > [email protected] > http://imagej.net/mailman/listinfo/imagej-devel > >
_______________________________________________ ImageJ-devel mailing list [email protected] http://imagej.net/mailman/listinfo/imagej-devel
