New features in ACD files for 2.0.0
Peter Rice
peter.rice at uk.lionbioscience.com
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).
Attributes:
name report file name
extension file name extension
Qualifiers:
-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 ]
Attributes:
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)
Types:
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
things
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
yet
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:
http://www.uk.embnet.org/Software/EMBOSS/Doc/interfaces.html
--
------------------------------------------------
Peter Rice, LION Bioscience Ltd, Cambridge, UK
peter.rice at uk.lionbioscience.com +44 1223 224723
More information about the emboss-dev
mailing list