[ImageJ-devel] MenuService/AbstractSwingUI issues

[Curtis Rueden]

Hi everyone,

Dscho and I have been discussing the ShadowMenu design, and we have a plans
for several improvements:

Multiple menu bars are not synced properly:
  http://code.imagej.net/trac/imagej/ticket/985

More context sensitivity is required for modules in menus:
  http://code.imagej.net/trac/imagej/ticket/987

More intelligent syncing between ShadowMenu and UI-specific menus:
  http://code.imagej.net/trac/imagej/ticket/988

it appears to me that AbstractSwingUI might be a bit too limiting at the
> moment with its builtin assumption that there is only one appFrame and
> that all menu item changes should be applied to that appFrame's
> application menu bar.
>

> So now I face the problematic situation where method calls to a ShadowMenu
> (which was already connected to a given JMenuBar using the
> SwingJMenuBarCreator -- why are there so many layers BTW?
> AbstractMenuCreator>AbstractSwingMenuCreator>SwingJMenuBarCreator?) are
> always redirected to the IJ2 menu bar -- which is bad when you want them
> to appear in the Script Editor's menu bar.
>

Yes, hopefully addressing ticket #988 will solve this problem.

Regarding the layers, for the benefit of any curious lurkers: there is an
unfortunate extra layer whose sole purpose is to work around the fact that
both Swing and AWT menu classes do not implement common interfaces where
their methods overlap. For example, all three of JMenuBar, JMenu and
JPopupMenu implement the common method add(JMenuItem) but there is no
common superclass or superinterface containing this method which can be
used in our code. So in short, we need separate JMenuBarCreator,
JMenuCreator and JPopupMenuCreator classes. To maintain DRYness (Don't
Repeat Yourself!) of code, there is an AbstractSwingMenuCreator class which
provides most of the needed code, leaving the aforementioned three
subclasses to implement a couple of remaining methods.

Lastly, the overlong names are to avoid name clashes between classes. We
have made an effort in ImageJ2 to avoid having two classes with the same
name in different packages. For example, for brevity we could have
imagej.ext.ui.swing.MenuCreator and imagej.ext.ui.awt.MenuCreator, both of
which implement imagej.ext.menu.MenuCreator. But that would be quite
confusing. In the case of Swing we could call the implementation e.g.
JMenuCreator rather than SwingJMenuCreator. However, that would not work
for AWT, which would simply be "MenuCreator" again, hence a name clash, so
we chose AWTMenuCreator instead. For consistency, all the Swing stuff is
generally called "SwingThisOrThat" with AWT called "AWTThisOrThat" and so
on. If people strongly dislike these names, we welcome alternative
suggestions.

Now, the MenuEvent knows pretty well which ShadowMenu it belongs to, but
> apparently no class feels responsible to retain the connection between the
> ShadowMenu and the SwingJMenuBarCreator used to turn this into an
> instance.
>

Right, ticket #988: maintain that connection.

Consequently, I do not see where it was intended to resolve this issue
> (this is related to the wasteful recreation of a complete menu bar
> whenever anything changed in any menu item).
>

Hopefully those tickets clarify the direction we are going with the menu
system.

Regards,
Curtis


On Mon, Feb 6, 2012 at 7:52 PM, Johannes Schindelin <schindelin at wisc.edu>wrote:

> Hi,
>
> it appears to me that AbstractSwingUI might be a bit too limiting at the
> moment with its builtin assumption that there is only one appFrame and
> that all menu item changes should be applied to that appFrame's
> application menu bar.
>
> So now I face the problematic situation where method calls to a ShadowMenu
> (which was already connected to a given JMenuBar using the
> SwingJMenuBarCreator -- why are there so many layers BTW?
> AbstractMenuCreator>AbstractSwingMenuCreator>SwingJMenuBarCreator?) are
> always redirected to the IJ2 menu bar -- which is bad when you want them
> to appear in the Script Editor's menu bar.
>
> Now, the MenuEvent knows pretty well which ShadowMenu it belongs to, but
> apparently no class feels responsible to retain the connection between the
> ShadowMenu and the SwingJMenuBarCreator used to turn this into an
> instance.
>
> Consequently, I do not see where it was intended to resolve this issue
> (this is related to the wasteful recreation of a complete menu bar
> whenever anything changed in any menu item).
>
> Help?
> Johannes
>
> _______________________________________________
> 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/20120221/347d0365/attachment.html>