Hi everyone,<div><br></div><div>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: <a href="http://developer.imagej.net/menuing-system">http://developer.imagej.net/menuing-system</a>).</div>

<div><br></div><div>There are currently three issues with it:</div><div><br></div><div>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 <a href="http://trac.imagej.net/ticket/1162">http://trac.imagej.net/ticket/1162</a> for details.</div>

<div><br></div><div>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 <a href="http://trac.imagej.net/ticket/1161">http://trac.imagej.net/ticket/1161</a>) on the fix-menus branch, which avoids making these copies.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>Regards,</div><div>Curtis</div><div><br></div>