I am not sure I completely understand the suggestion. We thought of menus that really appear “inside” the hyperstack window, like for Bdv when using Windows. I know this is a bit against the ImageJ1 philosophy, but it would have the advantage that there is no doubt on which image one is operating when selecting a menu entry. Maybe we have to reconsider though in order to stick with the general logic of each command running on the last image that someone clicked on…(in fact our initial reason of going for menu’s attached to the viewer window is that we could not figure out how to make the “last-image-clicked-on” logic work for Bdv viewer windows).
I guess what we are conceptually struggling with is that, e.g., each Bdv viewer window has its own B&C settings menu, whereas in there is only one B&C settings window for all IJ1 hyperstacks, operating on whatever has been clicked on last. Those are two different philosophies.
It’s more than just a philosophy: there are technical limitations, especially on macOS. If you have an AWT MenuBar or a Swing JMenuBar on macOS, it will appear at the top of the screen, matching the currently active window. If you want to have a window-specific menu bar like other platforms, there is a (JVM-global) system property apple.laf.useScreenMenuBar which must not be set to true. I do not know whether there is a way to override this setting on a window-by-window basis.
That is what I would strongly recommend. You will have a much easier time of it. Just lean on the SciJava @Plugin annotation’s menu and/or menuPath attributes. If you really hate how it works, we can talk about how to extend or change this functionality in general. But hacking up the hyperstack window to do menuing differently just for your plugins is a recipe for disaster.
It’s true. Maybe @tpietzsch wants to comment further on it, but I think what it comes down to is: BDV was designed to be used in contexts besides only the ImageJ application. It does not use the SciJava menu system. I did briefly discuss with @tpietzsch today some aspects of the SciJava ShadowMenu and MenuService architecture, such that BDV could potentially integrate more with it in the future. But it would help to have some concrete design goals or requirements before proceeding with any changes. For example: maybe we want BDV to expose Command plugins? Then you wouldn’t have to do any explicit menu hackery in order to make your stuff appear in the BDV menu…