New features in ACD files for 2.0.0

Peter Rice peter.rice at
Mon Jul 16 09:34:58 UTC 2001

New features in ACD files for 2.0.0

1. New ACD type

1.1 Report

Feature report, intended to replace the output file for applications
that write results which can be interpreted as 'features' (start and
end positions and score, with some possible annotation). These
applications will change to store their results internally as feature
tables, and will write reports using a default format (similar to
their present output), but can be given a command line option to write
the output in any other standard feature report format.

The initial report format is GFF, or any other feature format.

Attributes will be extended - for example to specify protein or DNA
features as this now affects the valid feature formats.

Further report types will be added to produce alignment output
(-aformat and so on for the qualifiers).


name           report file name
extension      file name extension


-rformat       report format
-ropenfile     report file name
-rextension    file name extension
-rname         base file name

2. GUI extensions

As proposed on the emboss-dev mailing list by James Bonfield, we now
have groups of ACD options. The basic grouping uses a 'section' and
'endsection' pair, with names to ensure correct usage. THese sections
can be nested.

Section names are intended to use a limited vocabulary so that they
can be converted to standard names in GUI interfaces. SRS, for
example, groups options in this way (see the blast launch options on
the EBI's SRS server).

2.1 Section

specified as:

section: name [ attribute: value ]


info     text that EMBOSS could (in future) use as a prompt
         before the first option in the section
comment  general comment, in case of need
type     type name ("frame" or "page", or undefined)

side     side specification (top, bottom, left, right) (for type: frame)
border   width of border (for type: frame only)

folder   folder name (for type: page only)


In James Bonfield's original specification, there are two special
types of section which display differently in his interface. "frame"
was intended to be the default, although this is not strictly
implemented in ajacd.c yet.

James' original descriptions (from the emboss-dev mailings, with the
attribute names updated):


type       A choice between "frame" and "page".
           Defaults to frame.
           This controls whether the section should be a labelled frame or
           a page in a notebook. The distinction only really matters for
           GUI or WWW based systems. In Tcl the choice is pretty clear. In
           WWW I'd expect a frame to be a table; a page is trickier to
           implement (and may require javascript), but I've seen such
           done regularly.

info       A heading for the frame or page. Defaults to ""
           A page without a heading would look rather odd, but a frame
           without a heading is OK - it's just a bordered block.

folder     Only needed for type:frame.
           The notebook to associate this page to. Defaults to "", which
           implies all pages are part of the same notebook. This is only
           needed if a program wishes to make use of more than one tabbed
           notebook, in which case this is used to determine which book a
           page is within.
           *Note* James originally called this 'book'

border     Only needed for type:frame. Defaults to 1.
           The border width of the frame.

side       Only needed for type:frame. Defaults to top.
           This is used for 'frame packing'. It is only needed if we wish
           to express complex layout designs. Eg:

           |            Section1              |
           |   blah                           |
           |   blah                           |
           | +-------------+ +--------------+ +
           | | Section2    | | Section3     | |
           | |   blah      | |   blah       | |
           | +-------------+ +--------------+ |

I think perhaps the border and side attributes are overkill, and I haven't
used them except in test ACD files. Naturally all of these are really just
"hints" to the interface, which may ultimately do whatever it prefers.


Note that SRS can handle these attributes reasonably well, so they
could be widely useful even if James does not eventually use them.

2.2 Other GUI hints in EMBOSS

(These were already in 1.0.0)

integers and floats (and arrays) have 'increment' to specify an
increment for GUIs which go beyond typing in a number.

lists and selects have 'button' and 'maximum' to specify whether to
use a pull down menu or selectin list, or a set of radio buttons or
checkboxes. 'Maximum' is so far always 1, but there is no reason why
multiple selections would not be used in future.

2.3 Command line interface

The new 'section/endsection' groups can be implemented in the command
line interface, for example by starting a new line and issuing the
'info' prompt before prompting for a value in a section. An obvious
example would be gap penalties for an alignment program.

We can expect to change the order of options in many applications to
fit them into sections. This will change the order in which programs
prompt the user, and will help us to standardise on where to place
prompts for output file and graph type.

3. Other GUIs

GUI authors are very welcome to help in this task. Has anyone tried
rearranging the ACD options for other interfaces?

It would be useful to have a status report from each of the EMBOSS GUIs.
The current list of known EMBOSS GUIs and otehr interfaces is at:

Peter Rice, LION Bioscience Ltd, Cambridge, UK
peter.rice at +44 1223 224723

More information about the emboss-dev mailing list