The main point of
InteractiveCommand is to mark that you want the dialog box to be non-modal. For convenience, it implements
Interactive, and calls
run() every time any parameter value changes, although this behavior can be overridden.
Certainly we want the parameter-based GUI to be both powerful and convenient. However, the primary requirement is that it be agnostic to the UI. It is declarative, and up to each application (e.g., ImageJ, KNIME, CellProfiler, OMERO, headless CLI) to decide exactly how to harvest the parameters. I am reluctant to add very fancy things which require complex logic in the
scijava-ui-swing component, because not all applications leverage that component. When developers inevitably lean on those fancy things in clever ways, their commands will de facto work only in ImageJ, and not in those other paradigms. I very much want to discourage this situation from happening.
On the other hand, I do also want to make it possible to craft nice dialogs, comparable at least to the ImageJ 1.x
GenericDialog et. al. Otherwise, everyone will just code their own Swing dialog (or stick with the IJ1 stuff), and then their commands still won’t be usable across the various paradigms. It is a tough balancing act.
We could trigger callbacks when values are initially set during preprocessing, although we may want to be careful with this. It seems to me that in your case, the correct/intuitive behavior is indeed to respond to a callback on the
File parameter, updating the matching