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:
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!