Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow plugin parameters to be hidden #42

Open
ctrueden opened this Issue May 1, 2014 · 10 comments

Comments

Projects
None yet
7 participants
@ctrueden
Copy link
Member

commented May 1, 2014

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

This comment has been minimized.

Copy link

commented Aug 29, 2015

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

This comment has been minimized.

Copy link

commented Oct 26, 2016

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

This comment has been minimized.

Copy link
Member

commented Jul 4, 2017

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

This comment has been minimized.

Copy link
Member

commented Sep 27, 2017

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

/cc @milkyklim

@imagejan

This comment has been minimized.

Copy link
Member

commented Sep 27, 2017

@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

This comment has been minimized.

Copy link
Member Author

commented Sep 27, 2017

@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-ops 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):

widgets

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 comment has been minimized.

Copy link
Member

commented Sep 28, 2017

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

This comment has been minimized.

Copy link

commented Dec 11, 2017

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

@sudgy

This comment has been minimized.

Copy link

commented Aug 13, 2018

@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

This comment has been minimized.

Copy link
Member Author

commented Aug 23, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.