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 <[email protected]> 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 <[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
