More ACD GUI bits

[James Bonfield]

In addition to the previous note, here's my proposed additions to the ACD
syntax. Forgive the woolly use of terms - I'm new to emboss and so don't know
the correct terms for acd components.

New types "frame" and "page". These are useful for graphical environments that 
want to group questions together in logical blocks. The frame attribute could
be added to any other type. An example shows this best:

frame: seqs [
    info: "Select sequences"
]

sequence: sequencea [
    param: y
    type: any
    frame: seqs
]

sequence: sequenceb [
    param: y
    type: "@($(sequencea.protein) ? protein : nucleotide)"
    frame: seqs
]

here both sequencea and sequenceb would be wrapped up inside their own frame,
with an associated border. This could be a real "frame" in the Tk sense, or a
table cell in an HTML interface. The info line is just a title for the frame,
should the GUI in question wish to present frames in that manner.

page is much the same thing, except it would represent pages on a tabbed
notebook. For ultimate flexibility we should not disallow hierarchial
definitions, just as long as they're in the correct order. For example:

page: sequences [
    info: "Sequences"
]

frame: seqs [
    page: sequences
    info "Select sequences"
]

and even

frame: seq1 [
    frame: seqs
]

(Although I'm clutching at straws to get a good real-world example here.)

Clearly the command line ACD parser can simply skip these.Does anyone have any
more suggestions for GUI structuring?

My plan, already partially implemented, is to have an acd to tcl code
generator. Each primary acd type (seqall, int, etc) relates precisely to a
portion of generated code based around a tk megawidget of the same type. This
has already been implemented here by Kathryn Beal, but she worked from the xml
definitions produce by PISE's acd2xml convertor. Unfortunately that's the
cause of many of our problems at present, hence the decision to go directly
from acd. (Kathryn's SPIN does work well however, so I'll be reusing
everything except the emboss dialogue generation code.)

It's also evident that some of the programs have so many options that the
dialogues simply do not fit on the screen. In such cases it's also obvious
that the reason is due to lots of tweaking parameters which the average user
would rather not see, but which the power use may ultimately like to
use. Hence the idea of using a tabbed notebook to separate these out. We could 
look at the "optional" ACD attribute and automatically split the questions
into the appropriate tabs, but this doesn't give us as much flexibility.

Any thoughts on this idea would be much appreciated.

-- 
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/