required vs optional

[James Bonfield]

Hi Peter,

Thanks for some clarification, but I still have further queries.

> If you say "req: Y" then it means required, and will be prompted.
> If you say "param: Y" this also means required, and will be prompted.

So for the purposes of the GUI I can just treat them the same and always
specify the qualifier anyway.

> If you want to make life complicated, you can say "req: <expression>" and work
> out at run time whether it is required or not. These are the cases that cause
> you problems. If you can figure out the result, then fine. If not, you can

Actually these aren't a problem at all. I'm handling expressions already, even 
in cases for specifying the minimum and maximum values (I don't know if these
exist, but I hacked an example to test it). So my GUI for stretcher, for
example, automatically handles changing the gappenalty and gaplength
parameters when the user changes from DNA to protein or back again. If the
user modifies gappenalty and then changes the sequence type then the program
remembers that the user has already adjusted the value and so it then does not
automatically change it.

Internally this is all performed by Tcl's excellent variable trace
options. When a value is an expression I work out which variables are
contained within the expression and produce a Tcl trace for each one. Then
whenever a dependent variable is modified a callback procedure is invoked
which reevaluations the expression. This is even working (wrongly as it turns
out) for the required parameters, so setting $(wheel) to 0, from 1, (for
example) could automatically grey-out the other parameters.

> would make life even more difficult for interface developers if we had too
> many expressions. The obvious solution would be to say "opt: $(wheel)" in
> steps. 

To be honest it'd make my life easier as things are more consistent, and it
looks better for the user too.

> Of course, you are free to play with the settings to find a way that makes
> sense for your graphical interface. Most variations would make sense to the
> program (just try it from the command line to check what happens).

I still feel that a way of indicating unnecessary or pointless questions would 
be useful. It's additional to required as that just indicates whether or not
the default value is enough. I'm just trying to think what dialogues
professional applications are likely to have, and greying-out things on the
fly is a common technique. The more I think about it the more I'm certain.
So I propose the following addition to each command line qualifier.

needed: @expression

The default is 1. If an expression is specified and it evaluations to 0 then
the option is not asked for (even with -options) and in GUIs it will be
greyed-out. For me, this is trivial to do (ie I've already written it).
Any comments on this proposal?


James

-- 
James Bonfield (jkb at mrc-lmb.cam.ac.uk)   Tel: 01223 402499   Fax: 01223 213556
Medical Research Council - Laboratory of Molecular Biology,
Hills Road, Cambridge, CB2 2QH, England.
Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/