Would it be better to list plugins by feature ontology?



It seems the current bias is to consolidate plugins under update site names, but this is making Fiji increasingly more difficult to use, as the names of the update sites have no correlation with the plugins they contain, and update sites will often have multiple plugin types, and multiple update sites will have the same plugin type, resulting in a giant, obfuscated plugin menu.

I’m wondering if it would not be much better to have a set of standardized, hierarchical ontology rules (such as the category list on the FIJI wiki page) to organize plugins, and ask developers to list their plugins under these names. That way, I would look for a watershed algorithm under “segmentation”, rather than MorphoLibJ, and the morphological filters in MorphoLibJ would be listed under a “filters” category along with things like Beat’s Anisotropic diffusion.

I also think this would greatly increase adoption of new plugins, as lay-people will see new plugins listed under the main function they perform (i.e. registration, convolution, filtering, transformation, etc.) so users will already have an idea what the plugin is supposed to do based on its category.

I know this would take some coordination and poking people, but it would be trivial for developers to implement, as it simply requires a two second modification to the config file. It also feels like if this current trend continues, there will be hundreds of update sites, resulting in a mile long plugin menu. By that time, there will be that much more inertia to overcome to change anything.

Just my own two cents,
Ben Smith


I think it’s a great idea !
It could be worth listing it as an enhancement issue somewhere in GitHub @imagejan @ctrueden @frauzufall


I agree this issue should be filed on GitHub. Probably in https://github.com/fiji/fiji/issues, since Fiji is the distribution most affected by messy menus. This issue should be a general “menu cleanup” issue. It has come up several times in the past (feel free to search and dig up links to old conversations; that would be helpful). There is currently one issue about cleaning up the Help menu (imagej/imagej-legacy#115) but it does not cover the scope of what needs to be done even for the Help menu alone, much less for the entire menu structure.

I believe that approach was the original goal of the Fiji menu design under Plugins. You can see it historically, that many of the older plugins are indeed categorized in that way. The problem is that there is no enforcement for the past few years, so people just do whatever they want.

Clear documentation about how things should be organized in Fiji would be most welcome. I personally do not have the bandwidth to develop, define or enforce this, but would be 100% supportive if someone else wants to do so.

Be careful saying something is technically trivial. For example, one paramount concern is backwards compatibility.

Fortunately, one nice thing in terms of backwards compatibility of macros is that moving menu items between menus does not break backwards compatibility—only renaming the leaf items breaks it. If renames of menu commands themselves are deemed necessary, we can also include backwards-compatible stubs to call the renamed commands, so that old macros continue to work.

I agree about the menu getting increasingly long being a problem. I do not think the inertia will grow, though—on the contrary, the more annoyingly long it gets, the more impetus we have to fix it.


There is an issue already :wink: :

and from there you already linked to two relevant forum discussions: