[ImageJ-devel] Menuing system discussion

[Curtis Rueden]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120611/77eba4db/attachment.html>