Hi everyone,<br><br>Dscho and I have been discussing the ShadowMenu design, and we have a plans for several improvements:<br><br>Multiple menu bars are not synced properly:<br> <a href="http://code.imagej.net/trac/imagej/ticket/985">http://code.imagej.net/trac/imagej/ticket/985</a><br>
<br>
More context sensitivity is required for modules in menus:<br> <a href="http://code.imagej.net/trac/imagej/ticket/987">http://code.imagej.net/trac/imagej/ticket/987</a><br>
<br>
More intelligent syncing between ShadowMenu and UI-specific menus:<br> <a href="http://code.imagej.net/trac/imagej/ticket/988">http://code.imagej.net/trac/imagej/ticket/988</a> <br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
it appears to me that AbstractSwingUI might be a bit too limiting at the<br>
moment with its builtin assumption that there is only one appFrame and<br>
that all menu item changes should be applied to that appFrame's<br>
application menu bar.<br></blockquote><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><br></blockquote><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So now I face the problematic situation where method calls to a ShadowMenu<br>
(which was already connected to a given JMenuBar using the<br>
SwingJMenuBarCreator -- why are there so many layers BTW?<br>
AbstractMenuCreator>AbstractSwingMenuCreator>SwingJMenuBarCreator?) are<br>
always redirected to the IJ2 menu bar -- which is bad when you want them<br>
to appear in the Script Editor's menu bar.<br></blockquote><div><br>Yes, hopefully addressing ticket #988 will solve this problem.<br><br>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.<br>
</div><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Now, the MenuEvent knows pretty well which ShadowMenu it belongs to, but<br>
apparently no class feels responsible to retain the connection between the<br>
ShadowMenu and the SwingJMenuBarCreator used to turn this into an<br>
instance.<br></blockquote><div> </div><div>Right, ticket #988: maintain that connection.<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Consequently, I do not see where it was intended to resolve this issue<br>
(this is related to the wasteful recreation of a complete menu bar<br>
whenever anything changed in any menu item).<br></blockquote><div><br>Hopefully those tickets clarify the direction we are going with the menu system.<br><br>Regards,<br>Curtis<br><br></div></div><br><div class="gmail_quote">
On Mon, Feb 6, 2012 at 7:52 PM, Johannes Schindelin <span dir="ltr"><<a href="mailto:schindelin@wisc.edu">schindelin@wisc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
it appears to me that AbstractSwingUI might be a bit too limiting at the<br>
moment with its builtin assumption that there is only one appFrame and<br>
that all menu item changes should be applied to that appFrame's<br>
application menu bar.<br>
<br>
So now I face the problematic situation where method calls to a ShadowMenu<br>
(which was already connected to a given JMenuBar using the<br>
SwingJMenuBarCreator -- why are there so many layers BTW?<br>
AbstractMenuCreator>AbstractSwingMenuCreator>SwingJMenuBarCreator?) are<br>
always redirected to the IJ2 menu bar -- which is bad when you want them<br>
to appear in the Script Editor's menu bar.<br>
<br>
Now, the MenuEvent knows pretty well which ShadowMenu it belongs to, but<br>
apparently no class feels responsible to retain the connection between the<br>
ShadowMenu and the SwingJMenuBarCreator used to turn this into an<br>
instance.<br>
<br>
Consequently, I do not see where it was intended to resolve this issue<br>
(this is related to the wasteful recreation of a complete menu bar<br>
whenever anything changed in any menu item).<br>
<br>
Help?<br>
Johannes<br>
<br>
_______________________________________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagej.net">ImageJ-devel@imagej.net</a><br>
<a href="http://imagej.net/mailman/listinfo/imagej-devel" target="_blank">http://imagej.net/mailman/listinfo/imagej-devel</a><br>
</blockquote></div><br>