[ImageJ-devel] Menuing system discussion

[Barry DeZonia]

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 <ctrueden at wisc.edu> 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
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120612/fe0f9b08/attachment.html>