Customize menus in Fiji

Hello everyone,
I was wondering to what extent it is possible to customize the menus of Fiji.
I would like to produce a user-friendly package for the people in our lab, without features that are out-of-date or irrelevant to our work. For example, I think there is no point keeping the Analyze/Surface plot entry, since it is superseded by the 3D surface plot. In the same manner, some entries can be confusing to newcomers, such as the “Threshold” option in the Image menu, which does not threshold the image as “Adjust/Threshold” does.
I know I can edit the plugins.config file for some plugins, and rearrange some items in the ij.props file, but there are still a lot of entries for which I have no idea.
Thank you for your help.

Welcome to the forum, @Nicolas!

In Fiji—actually, at the ImageJ2 level—there are a few different ways to customize the menu. But before we discuss that…

Perhaps it is worth discussing whether to make some such changes to the Fiji distribution itself, to clean things up for everyone, rather than only for your group. What do you think? Do you have a list of proposed changes to discuss?

The menu structure of Fiji is certainly up for debate. In particular, hiding obsolete menu items makes sense—we can keep those functions around so they keep working in macros and scripts, while removing them from the UI so that people do not stumble upon now-discouraged commands.

The fact is that the current maintainers do not really have time to do a “menu audit”—but if you have the energy, I would be very happy to help facilitate making your proposed changes a reality. We just have to be a little careful about backwards compatibility.

1 Like

@Nicolas,
Another approach, if you really want to create a streamlined interface, is to use the Action Bar plugin. I did this for a group in my lab, and they only have to worry about 4 buttons during normal use.

1 Like

Hello Curtis,

thank you for your answer. Actually, I wish I could contribute to make Fiji more accessible, especially for people who don’t specialize in image analysis. I work in a materials science unit, and I always have to struggle a little bit to make the students use Fiji instead of the fancy commercial microscope programs - which can deliver absolutely non-reliable results, but in a user-friendly way. I also have the feeling I miss a lot of essential features because they are hidden somewhere in the menus.

It’s been quite a while I had the idea of “disassembling” Fiji to evaluate each of its functions, but I must admit I have little time for that.

Some functions may be outdated, some may be of little use (the Shadows entry in Process?), some of them are duplicates (how many versions of 3D filters do we have now?), and some of them are almost outstanding, except that they have no documentation, or haven’t been updated in the last 10 years. I know that the most active developpers of Fiji are aware of that, and the creation of Ops is a great step towards more simplicity.

I am not sure already how I would rearrange the menus if I could, but for sure, I don’t think that having different entries with the same name is a good practice :

  • Image>Adjust>Threshold vs Image>Threshold
  • Process vs Plugins>Process
  • Image>Stacks vs Plugins>Stacks
  • Process>Morphology (gray morphology) vs Plugins>Morphology (G. Landini’s plugins)

And some entries are vague (like, hm, “Process”, or “Analyze”, or Analyze>Tools. Actually, everything is a tool).

Here I’m pointing at the flaws of Fiji, or at least at what appears as flaws to me, but I must say I don’t have a ready-made solution. Perhaps the first step would be to identify the functions that are obsolete or that can be replaced. Then, those that are duplicate, or similar (e.g. Image>adjust size vs Image>Scale vs TransformJ).

Jim, thank you for your suggestion. I already use ActionBar and it is true that it is convenient for a limited number of options.

2 Likes

Yes, I think lack of time is the reason why still nobody has tackled this. And the Command Finder makes it too easy to find things, so the pressure is not high enough to do some spring cleaning in the menus.

I think a “menu audit” could be tackled from two sides:

  • Identifying obsolete items and removing them from the UI (while keeping them accessible via scripting), as suggested by @ctrueden
  • Identifying a general menu hierarchy with categories that are agreed-upon in the community, and easy to grasp for newcomers.

Rainer Engel had started a similar discussion on the mailing list, but it seems also he didn’t find the time to pursue it. But his list of categories could serve as a starting point for identifying a well-structured menu hierarchy: https://edupad.ch/V44Z6j0MLG


Another issue is the full freedom for plugin developers to put their command at any place in the menu. While it facilitates custom workflows and prototype testing (you don’t need to dive deep into the Plugins menu), it creates confusion on the user side, especially for newbies.
Maybe we could at the same time draft a kind of “policy” to guide plugin developers to correctly categorize their commands and put them into the according place in the menu.

1 Like

Thanks @imagejan. Fiji used to be more focused on consistent categorization of plugins in the menus. But during and since the transition to ImageJ2, this focus was lost. However, I am certainly in favor of drafting a policy here. I would recommend we do it in two “layers”: 1) a page detailing the recommendations / best practices to which all plugin authors are encouraged to adhere; and 2) updating the Fiji contribution requirements to state that all core Fiji plugins must abide by those recommendations.

1 Like

Given the modular nature of ImageJ, it will require some effort to maintain a coherent menu hierarchy. While ago I had also started to compile a list of “misplaced” menu entries. I never completed it, but this is what I came up with:

  1. Merge Plugins>Optic Flow> with Analyze>Optic Flow>
  2. Move Plugins>Janelia H265 Reader to File>Import>Janelia H265 Reader
  3. Rename Plugins>Examples to Plugins>Scripting Examples
  4. Move Plugins>MTrackJ to Plugins>Tracking>MTrackJ
  5. Move Plugins>NeuronJ to Plugins>Segmentation>Tracing>NeuronJ
  6. Move Plugins>Segmentation>Simple Neurite Tracer to Plugins>Segmentation>Tracing>Simple Neurite Tracer

From this list, I guess we could propose some initial guidelines:

  • If a submenu already exists elsewhere in the IJ Menu hierarchy, try to re-use rather than recreating an identical entry in Plugins> (#1, above)
  • I/O plugins should be registered in File> (#2, above)
  • Prefer menu labels that favor meaningful alphabetical sorting of pre-existing menu entries: e.g., Plugins>Filters (John Doe)> is a better choice over Plugins>John Doe Filters>, as the former will be listed together with existing entries starting with Filter (#3, above)
  • Avoid registering single commands directly in Plugins>. Prefer a submenu instead (#4 and #5, above)

Arguably, these may not even be good guidelines and following these would still cause problems (what to do when a submenu becomes extremely long? or what to do to avoid the propagation of spurious submenus?) But perhaps this could be used as a starting point?

BTW, Here is the list of the affected plugins and respective update sites from my list. @Nicolas, perhaps you would like to add your own compilation, so that maintainers of the offending commands can have a look at it?)

    | Menu entry                    | Plugin                | Update site  |
    |-------------------------------|-----------------------|--------------|
    | Plugins>Optic Flow            | mpicbg_               | Fiji         |
    | Plugin>Examples               | Examples              | Fiji/Java-8  |
    | Plugins>MTrackJ               | MtrackJ               | ImageScience |
    | Plugins>NeuronJ               | NeuronJ               | ImageScience |
    | Plugins>Janelia H265 Reader   | H5j_Reader            | Fiji         |
    | Plugins>Simple Neurite Tracer | Simple_Neurite_Tracer | Fiji         |

4 Likes

Just a heads up: I finally filed an issue to track a planned reorganization of the Fiji menu structure, along the lines discussed above.

3 Likes

Hi all,

Sorry to revive an ancient thread, but I didn’t want to create a new thread for what is essentially the same topic. During our time at home I decided to try and make an ImageJ2 plugin that would allow users to customize the menu by essentially creating their own Menu Tree hierarchy, which gets saved as a file and loaded in as the menu instead of how it normally builds the menu upon starting Fiji. Figured this would be a good compromise or bandaid to having to decide what we should keep or move around; people could just do it themselves if they want!

Well, it’s almost working… spent a long time trying to figure out how ImageJ2 builds the menus. I have a custom Menu Service that has a higher priority than DefaultMenuService that was intended to replicate all the same functions… and when I build ImageJ2 (without legacy) it seems to be working well. I can create a new menu, save it, and when I reload ImageJ2 the menu is customized (this is with Swing).

But I’m stuck, because when I try it in Fiji proper, the Legacy mode doesn’t seem to be building the menu the same way. Or for some reason, my CustomMenuService isn’t being called automatically on Startup. I thought since I was implementing MenuService with a higher priority, mine would take precedent… but it doesn’t seem to be starting until I click on the menu entry for its corresponding command.

Any chance someone might be able to guide me in the right direction? I am wondering if it’s because I have built the new service and the command as a part of the same JAR package, and so the service doesn’t start until I fire the command… or if it’s something to do with the Legacy interface… I’m lost unfortunately!

1 Like

Just kidding, I see now that in Legacy the menu is hardcoded, rather than dynamically generated. I guess as long as the legacy UI is default, it may not be possible to provide a plugin that rearranges the menu. Ah well.

1 Like