[ImageJ-devel] Menuing system discussion

[Barry DeZonia]

The double-plugin-launch branch has been merged to master and the branch
deleted. There is still some debugging to do.

On Tue, Jun 12, 2012 at 10:42 AM, Barry DeZonia <bdezonia at gmail.com> wrote:

> 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/9070e982/attachment.html>