Semi-hidden "advanced" options?
Hi all, Many command line tools have a lot of options - typically there is a short list of main options which will be commonly used, and a larger set of "advanced" options which are rarely used. I'd like to annotate the options in the XML file in this way, so that the "advanced" options are hidden by default. What I have in mind here is something like the NCBI BLAST web interface, where at the bottom of the page there is a little triangle icon next to "Algorithm parameters", clicking on this it expands to show more options. I've been reading the docs and don't see any mention of this kind of thing: http://bitbucket.org/galaxy/galaxy-central/wiki/ToolConfigSyntax Have I missed it, or would this be a feature request? Peter
An easy way to do this is using conditionals and a select parameter. The select would have two (or more) options like "Default Options" and "Advanced Options". When "Advanced Options" is selected, then display the previously hidden options. On Tue, Sep 21, 2010 at 11:36 AM, Peter <peter@maubp.freeserve.co.uk> wrote:
Hi all,
Many command line tools have a lot of options - typically there is a short list of main options which will be commonly used, and a larger set of "advanced" options which are rarely used. I'd like to annotate the options in the XML file in this way, so that the "advanced" options are hidden by default.
What I have in mind here is something like the NCBI BLAST web interface, where at the bottom of the page there is a little triangle icon next to "Algorithm parameters", clicking on this it expands to show more options.
I've been reading the docs and don't see any mention of this kind of thing: http://bitbucket.org/galaxy/galaxy-central/wiki/ToolConfigSyntax
Have I missed it, or would this be a feature request?
Peter _______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
-- Jesse Erdmann Bioinformatics Analyst Masonic Cancer Center University of Minnesota jerdmann@umn.edu 612-626-3123 jesse@jesseerdmann.com Twitter: http://twitter.com/jesseerdmann
The Bowtie and Tophat wrappers--which are included in the Galaxy distribution--provide nice examples of this approach. J. On Tue, Sep 21, 2010 at 2:34 PM, Jesse Erdmann <jerdmann@umn.edu> wrote:
An easy way to do this is using conditionals and a select parameter. The select would have two (or more) options like "Default Options" and "Advanced Options". When "Advanced Options" is selected, then display the previously hidden options.
On Tue, Sep 21, 2010 at 11:36 AM, Peter <peter@maubp.freeserve.co.uk> wrote:
Hi all,
Many command line tools have a lot of options - typically there is a short list of main options which will be commonly used, and a larger set of "advanced" options which are rarely used. I'd like to annotate the options in the XML file in this way, so that the "advanced" options are hidden by default.
What I have in mind here is something like the NCBI BLAST web interface, where at the bottom of the page there is a little triangle icon next to "Algorithm parameters", clicking on this it expands to show more options.
I've been reading the docs and don't see any mention of this kind of thing: http://bitbucket.org/galaxy/galaxy-central/wiki/ToolConfigSyntax
Have I missed it, or would this be a feature request?
Peter _______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
-- Jesse Erdmann Bioinformatics Analyst Masonic Cancer Center University of Minnesota jerdmann@umn.edu 612-626-3123
jesse@jesseerdmann.com Twitter: http://twitter.com/jesseerdmann _______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
On Tue, Sep 21, 2010 at 2:34 PM, Jesse Erdmann <jerdmann@umn.edu> wrote:
An easy way to do this is using conditionals and a select parameter. The select would have two (or more) options like "Default Options" and "Advanced Options". When "Advanced Options" is selected, then display the previously hidden options.
On Tue, Sep 21, 2010 at 8:13 PM, Jeremy Goecks <jeremy.goecks@emory.edu> wrote:
The Bowtie and Tophat wrappers--which are included in the Galaxy distribution--provide nice examples of this approach. J.
Thanks for the tip - it is a bit of a hack, but it will do the job :) Having this built into Galaxy as a feature would allow for a more intuitive interface, but it isn't essential by any means. Peter
On Wed, Sep 22, 2010 at 10:03 AM, Peter <peter@maubp.freeserve.co.uk> wrote:
On Tue, Sep 21, 2010 at 2:34 PM, Jesse Erdmann <jerdmann@umn.edu> wrote:
An easy way to do this is using conditionals and a select parameter. The select would have two (or more) options like "Default Options" and "Advanced Options". When "Advanced Options" is selected, then display the previously hidden options.
On Tue, Sep 21, 2010 at 8:13 PM, Jeremy Goecks <jeremy.goecks@emory.edu> wrote:
The Bowtie and Tophat wrappers--which are included in the Galaxy distribution--provide nice examples of this approach. J.
Thanks for the tip - it is a bit of a hack, but it will do the job :)
Having this built into Galaxy as a feature would allow for a more intuitive interface, but it isn't essential by any means.
I thought it would be more intuitive if these used the checkbox support, "Show advanced options: tick here", rather than a drop down with two choices. I've tried doing this by modifying one of the simpler examples, the FASTQ groomer - originally like this: <conditional name="options_type"> <param name="options_type_selector" type="select" label="Advanced Options"> <option value="basic" selected="True">Hide Advanced Options</option> <option value="advanced">Show Advanced Options</option> </param> <when value="basic"> <!-- no options --> </when> <when value="advanced"> ... </when> </conditional> Interestingly, using a condition based on a text field worked (the toggle takes effect when press enter, not as you type): <conditional name="options_type"> <param name="options_type_selector" type="text" label="Show advanced Options" value="advanced" /> <when value="basic"> <!-- no options --> </when> <when value="advanced"> ... </when> </conditional> However, I have been unsucessful in trying to use a checkbox: <conditional name="options_type"> <param name="options_type_selector" type="boolean" label="Show advanced Options" truevalue="advanced" falsevalue="basic" checked="false" /> <when value="basic"> <!-- no options --> </when> <when value="advanced"> ... </when> </conditional> I suspect that part of the problem is in lib/galaxy/tools/parameters/basic.py that the class BooleanToolParameter method get_initial_value returns a boolean (True/False) and not a string (the value given in the XML file, in my example "advanced" or "basic") like the other parameter classes. This change made some difference, but is not enough in itself (and I fear has side effects): --- a/lib/galaxy/tools/parameters/basic.py Fri Sep 24 10:38:45 2010 +0100 +++ b/lib/galaxy/tools/parameters/basic.py Fri Sep 24 11:42:38 2010 +0100 @@ -283,7 +283,10 @@ def to_python( self, value, app ): return ( value == 'True' ) def get_initial_value( self, trans, context ): - return self.checked + if self.checked: + return self.truevalue + else: + return self.falsevalue def to_param_dict_string( self, value, other_values={} ): if value: return self.truevalue Should <conditional> work with a checkbox (boolean) parameter? Thanks, Peter
On Fri, Sep 24, 2010 at 11:52 AM, Peter <peter@maubp.freeserve.co.uk> wrote:
On Wed, Sep 22, 2010 at 10:03 AM, Peter <peter@maubp.freeserve.co.uk> wrote:
I thought it would be more intuitive if these used the checkbox support, "Show advanced options: tick here", rather than a drop down with two choices.
...
I suspect that part of the problem is in lib/galaxy/tools/parameters/basic.py that the class BooleanToolParameter method get_initial_value returns a boolean (True/False) and not a string (the value given in the XML file, in my example "advanced" or "basic") like the other parameter classes. This change made some difference, but is not enough in itself (and I fear has side effects):
--- a/lib/galaxy/tools/parameters/basic.py Fri Sep 24 10:38:45 2010 +0100 +++ b/lib/galaxy/tools/parameters/basic.py Fri Sep 24 11:42:38 2010 +0100 @@ -283,7 +283,10 @@ def to_python( self, value, app ): return ( value == 'True' ) def get_initial_value( self, trans, context ): - return self.checked + if self.checked: + return self.truevalue + else: + return self.falsevalue def to_param_dict_string( self, value, other_values={} ): if value: return self.truevalue
Should <conditional> work with a checkbox (boolean) parameter?
I think the answer to my question is no one has every tried, because there are several things broken or not implemented here. First, I think that <conditional> get_current_case method currently only works with parameters where get_initial_value returns strings. This prevents it working on check boxes (booleans), and I assume also numbers (integer and float paramters). Second, the refresh_on_change="true" is only added to the HTML for select parameters (comboboxes/radio boxes), and not to checkboxes. The attached patch tackles the above two issues - but given the remaining problem I don't expect it to be committed as is. Third, having made sure refresh_on_change="true" is added to the HTML for checkboxes with dependencies, the refresh does not happen. This may be a JavaScript limitation? I've had a look at static/scripts/galaxy.base.js but it seems to only look for changes in comboboxes (?). I think a whole new JS function is needed to watch changes to checkboxes with the refresh_on_change="true" attribute. Am I on the right track? Would one of the main developers (who knows JavaScript) be able to make this work? Thanks, Peter
On Wed, Sep 22, 2010 at 10:03 AM, Peter <peter@maubp.freeserve.co.uk> wrote:
I thought it would be more intuitive if these used the checkbox support, "Show advanced options: tick here", rather than a drop down with two choices.
...
I've opened a bug report on this issue: http://bitbucket.org/galaxy/galaxy-central/issue/393/cant-use-checkbox-boole... Peter
Hi Peter,
Should <conditional> work with a checkbox (boolean) parameter?
I think the answer to my question is no one has every tried, because there are several things broken or not implemented here.
Yes, you are correct.
First, I think that <conditional> get_current_case method currently only works with parameters where get_initial_value returns strings. This prevents it working on check boxes (booleans), and I assume also numbers (integer and float paramters).
Second, the refresh_on_change="true" is only added to the HTML for select parameters (comboboxes/radio boxes), and not to checkboxes.
The attached patch tackles the above two issues - but given the remaining problem I don't expect it to be committed as is.
Thanks for the patch -- these appear to be necessary additions.
Third, having made sure refresh_on_change="true" is added to the HTML for checkboxes with dependencies, the refresh does not happen. This may be a JavaScript limitation? I've had a look at static/scripts/galaxy.base.js but it seems to only look for changes in comboboxes (?).
I think a whole new JS function is needed to watch changes to checkboxes with the refresh_on_change="true" attribute.
Am I on the right track? Would one of the main developers (who knows JavaScript) be able to make this work?
Yes, you are correct and are on the right track. It's straightforward to add JS support for refresh_on_change to a checkbox element. We'll look into this soon. Best, J.
On Mon, Sep 27, 2010 at 2:00 PM, Jeremy Goecks <jeremy.goecks@emory.edu> wrote:
Hi Peter,
Should <conditional> work with a checkbox (boolean) parameter?
I think the answer to my question is no one has every tried, because there are several things broken or not implemented here. ... Am I on the right track? Would one of the main developers (who knows JavaScript) be able to make this work?
Yes, you are correct and are on the right track. It's straightforward to add JS support for refresh_on_change to a checkbox element. We'll look into this soon.
Excellent. I do still think a separate mechanism for hiding parameters (which can be done with CSS) without all the complication of conditional code and refreshes would be more elegant - and probably much simpler for the wrapper writer. But that is a task for another day ;) Thank you, Peter
On Wed, Sep 22, 2010 at 10:03 AM, Peter <peter@maubp.freeserve.co.uk> wrote:
On Tue, Sep 21, 2010 at 2:34 PM, Jesse Erdmann <jerdmann@umn.edu> wrote:
An easy way to do this is using conditionals and a select parameter. The select would have two (or more) options like "Default Options" and "Advanced Options". When "Advanced Options" is selected, then display the previously hidden options.
On Tue, Sep 21, 2010 at 8:13 PM, Jeremy Goecks <jeremy.goecks@emory.edu> wrote:
The Bowtie and Tophat wrappers--which are included in the Galaxy distribution--provide nice examples of this approach. J.
Thanks for the tip - it is a bit of a hack, but it will do the job :)
To keep this simple, I'm initially making one option semi-hidden, the dust argument for blastn which I set to either "yes" (default) or "no". Starting from something like this: <command>blastn ... -dust $filter_query</command> ... <param name="filter_query" type="boolean" label="Filter out low complexity regions (with DUST)" truevalue="yes" falsevalue="no" checked="true" /> I could make the dust option conditional like so: <command>blastn ... -dust $adv_opts.filter_query</command> ... <conditional name="adv_opts"> <param name="adv_opts_selector" type="select" label="Advanced Options"> <option value="basic" selected="True">Hide Advanced Options</option> <option value="advanced">Show Advanced Options</option> </param> <when value="basic"> <param name="filter_query" type="hidden" value="yes" /> </when> <when value="advanced"> <param name="filter_query" type="boolean" label="Filter out low complexity regions (with DUST)" truevalue="yes" falsevalue="no" checked="true" /> </when> </conditional> It took me a while to realise the template name had to be changed in the <command> definition to include the conditional name prefix. Looking at the examples people pointed to, for example bowtie_wrapper.xml, bwa_wrapper.xml, velvetg.xml or fastq_groomer.xml, they don't try and define default hidden values when in "basic" mode. Instead there is some "magic" in the <command> definition. Is that documented somewhere? It isn't covered in http://bitbucket.org/galaxy/galaxy-central/wiki/ToolConfigSyntax Which approach is preferable and why? Peter
participants (3)
-
Jeremy Goecks -
Jesse Erdmann -
Peter