Access to ImageJ2 Input Harvester generated elements

Hello all,
Is there any possibility to get access to the GUI elements in the generic dialog after it has been generated by the Input Harvester?

Some examples I would like to improve:
Right aligned buttons of different size do not look very nice, a centered position would be far more better.
The same for pure text labels (messages).

Setting of elements’ visibilities would increase the usability of the GUI.
Depending on a main option (e.g radio button), some sub options should be deactivatable.

Thanks in advance,

At least with ImageJ-1, most of what you like to see is possible, especially when using the “dialogItemChanged”-method.
It takes some planning though.

At least for the Mac, the final button-row is right aligned.

Given you explicitly mention #imagej2 in the topic title, I guess that you’re not referring to the ij.gui.GenericDialog class of ImageJ1 here, right?

One of the design goals of ImageJ2 was to separate concerns, i.e. make the plugin functionality independent of a specific user interface and platform.

A huge benefit of plugins being UI-agnostic is that they run without problems in “headless” environments (i.e. setups without any graphical user interface), or when embedded in other application frameworks such as KNIME (where IJ2 plugins will be available as auto-generated nodes).

As soon as you put UI-specific logic into your plugin, you might lose those benefits (which might be an acceptable cost for you, depending on what you want to achieve…).

In order to keep your plugin UI-agnostic, but still improve the user experience (or at least the graphical appearance…), I suggest that you:

  • contribute some improvements to the scijava-ui-swing component (with potential benefit to the whole community) by submitting a pull request:

The input panel of the dialog is implemented here in SwingInputPanel:

The dialog itself is implemented here:

Specific widgets are implemented in their own classes, e.g. for buttons:

Alternatively, you can:

  • override the input harvester implementation (or extend SwingInputHarvester with your own implementation). SciJava (the backing framework for IJ2) is fully extensible at runtime, so if you provide a PreprocessorPlugin that has a higher priority than SwingInputHarvester, that plugin will take precedence, and you can implement any UI elements according to your needs, without having to bake UI logic into your plugin itself.

Can you post an example screenshot to illustrate what you mean? We can discuss here or in a GitHub issue how to improve things (in a platform-independent way).

I believe this issue is what you mean:

That’s a common requirement in the community, and unfortunately still poorly supported by the SciJava framework. Here’s a related GitHub issue:

You might also want to add your specific use case to the “high-level” issue I created here:


Dear @imagejan,
Thanks a lot for this comprehensive list of suggestions!

Given you explicitly mention #imagej2 in the topic title, I guess that you’re not referring to the ij.gui.GenericDialog class of ImageJ1 here, right?

Yo are right, I am not refering to the ImageJ1 GenericDialog.

Here is a screenshot GUI as an example:

I added some extra “-” characters left and right to the text in order to shift them more to the center. With this messages, I intend to structure options into topics. There are still to come some more options.

The two surrogate options should only be active for the “Entire signal” radio button option and the “Box length” option only for the two "Box " radio button options.

Finally, the two bottons at the end have different size and are right-aligned.

It seems to me that left-aligned text messages and buttons would be the better choice compared to right-alignment, but this may be just my subjective view.

I will go through your suggestions and will see how to proceed.
Again, thanks a lot!
Best wishes,


Thanks @iqmmug for showing an example!

Regarding the visibility=MESSAGE parameters, adding a label=" " or similar might be a suitable workaround for now, as mentioned in the linked issue.

Your dialog looks like it could also benefit from a “grouping” option as implemented by @skalarproduktraum and discussed here:

1 Like