Allow plugin parameters to be hidden

[ctrueden]

Some modules may have differing inputs depending on the values of other inputs. For example, a thresholding plugin where you select which thresholding method to use may activate or deactivate certain secondary parameters depending on the method chosen.

I.e.: Command implementers might want the ability to show and hide parameters based on the settings of some current parameter. This could be done via its callback mechanism. Change the various UI harvester implementations to allow this behavior.

We could implement this by adding an "active" boolean state to each input. All inactive inputs are hidden in the UI. Also, all inputs inactive at the time the module is run would not be included when recording a script of that module execution.

Note: for simplicity and non-gui UIs, hiding parameters makes more sense than adding/deleting parameters.

Migrated-From: http://trac.imagej.net/ticket/683, http://trac.imagej.net/ticket/885

[adaerr]

I wonder whether it is not worth making a special case of purely UI
related changes like graying out/disabling or even making invisible
items which "aren't really parameters", such as Button widgets
(possibly also Visibility=MESSAGE parameters ? Here setting them to
'null' works at least in the ImageJ GUI on my box, where the dialog
rebuilds without it), to improve the user experience at least for
common GUIs: a greyed out Button is familiar (though it can be
frustrating when the cause for being greyed out is not obvious), and
less disruptive for the workflow than an active Button that either
does nothing, or pops up a message, or logs an error.

If the UI doesn't support graying out then setting invisible or even
doing nothing can be reasonable fallbacks: the callback should check
anyway if the conditions for its action are met. In any case this
requires at most a redraw of the UI, and does not affect the
collection and recording of the parameters (as opposed to altering the
type and/or number of parameters [1]).

[1]
http://imagej-devel.54429.x6.nabble.com/parameter-choice-update-in-component-callback-td1083.html#message1088

[2] see also
http://imagej-devel.54429.x6.nabble.com/feature-request-disable-Button-from-plugin-callback-tp1116.html

[omaraa]

Rather than adding an 'active' state, a more generic solution might be to add a visibilityFunction attribute to declare a method (as Java calls them...) which returns a value for 'visibility', or allowing the visibility attribute to take a method name, similar to 'callback'. Then on initialisation and when any parameter is modified the visibilityFunctions can be called and the UI harvester redrawn if there are any changes. Given an ItemVisibility.HIDDEN option, some code to toggle visibility of secondary (advanced settings) parameters might look like this:

    @Parameter(visibility = ItemVisibility.INVISIBLE)
    private boolean showAdvanced;

    @Parameter(visibilityFunction = "getAdvancedVisibility")
    private int advancedOptionA;

    @Parameter(visibilityFunction = "getAdvancedVisibility")
    private int advancedOptionB;

    private ItemVisibility getAdvancedVisibility()
    {
        return showAdvanced ? ItemVisibility.NORMAL : ItemVisibility.HIDDEN;
    }

Adding an ItemVisibility.DISABLED option would also make it straightforward to provide the familiar UX that adaerr described. Obviously developers would need to take care not to run computationally expensive code in these functions to prevent lag in the GUI.

[imagejan]

I'm not sure about the current status of the parameter visibility implementation. When testing with scripts, only the MESSAGE option seems to have an effect:

#@String(visibility=NORMAL, value="T1") t1
#@String(visibility=TRANSIENT, value="T2") t2
#@String(visibility=INVISIBLE, value="T3") t3
#@String(visibility=MESSAGE, value="T4") t4

println t1
println t2
println t3
println t4

As stated in the posts above, it would be very useful to have some possibility to dynamically set the visibility of an input item on a UI level, e.g. by greying out mutually exclusive options dependent on the state of another (boolean or choice) parameter.

This goes in line with improving the parameter validation, see #47.

[stelfrich]

We were wondering what the status on this issue was, @ctrueden? Especially with respect to (macro) recording of Services?

/cc @milkyklim

[imagejan]

@stelfrich wrote:

Especially with respect to (macro) recording of Services?

This is unrelated to visibility of parameters in UI widgets, no?

In general, Service parameters should not get recorded by the recorder, see the discussion in imagej/imagej-legacy#170.

[ctrueden]

@dietzc and I actually made big progress on related issues during the still-ongoing Konstanz hackathon. It's on the dev branch of scijava/scijava right now, but the goal is to move it to scijava-common or scijava-types soon. This will be part of SJC3 and a revamped widget framework, with a goal of releasing something as part of the December hackathon in Dresden.

With this scheme, you won't need all these callbacks to enable or disable parameters, in the case where the value of a dropdown box controls which controls are visible.

Here is a proof-of-concept preview (UI still needs polish):

For those scrutinizing the code, please also note that the use of the ObjectService to inject the available choices for the Joke is just a temporary placeholder for a more flexible mechanism for defining these choices.

[stelfrich]

This is unrelated to visibility of parameters in UI widgets, no?

It is: sorry 😞 ! This issue was the first one that turned up during a search...

With this scheme, you won't need all these callbacks to enable or disable parameters, in the case where the value of a dropdown box controls which controls are visible.

Thanks for the update, @ctrueden!

[tischi]

@ctrueden Looks very good to me! I think that'd be very useful!

[sudgy]

@ctrueden, when do you think this feature will be released? You said that you were thinking of doing it last December, but it's been a while since then.

[ctrueden]

@sudgy We are actively working on SciJava 3 / SciJava Ops during the next 3 months, and the updated widget framework is part of that work.

I doubt I will work on adding the ability to hide plugin parameters to SciJava 2 (the currently released incarnation).

I cannot promise when it will be released, but in general, SciJava 3 is a high priority.

[ctrueden]

For those following this thread: I just noticed that @sudgy implemented dynamic parameters here. Hardcoded to AWT, though.

[sudgy]

Yeah, I'm honestly not really any good with GUIs, I just got the bare minimum done for my purposes. If anybody wants to make a more modern implementation of DPDialog, be my guest.

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/repaint-scijava-command-ui/42835/2

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/access-to-imagej2-input-harvester-generated-elements/49338/3

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/dynamiccommand-not-displaying-without-error/60767/7

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/scijava-batch-processor/5548/17