Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://xmm.vilspa.esa.es/sas/5.4.1/doc/sas/node32.html
Дата изменения: Mon Jan 13 16:54:05 2003
Дата индексирования: Sat Dec 22 07:13:05 2007
Кодировка:
Поисковые слова: р р р с р с р р р с р с р р р с с р р с р с р р п п р п п п п
|
XMM-Newton Science Analysis System
sas (gui-1.37.5) [???]
Meta Index / Home Page / Developer's notes / Layout file
Layout guidelines
It is recommended that the following guidelines are followed when
developing tasks for use with the GUI:
- Use the special parameter types which are available (see documentation
of the param
package), so that the GUI can use appropriate widgets.
This makes it easier for the user to enter parameters and makes it
possible for the GUI to check their validity. For example, don't use
a string parameter for a filename; a filename parameter allows the
user to browse for a file with a file dialog.
- Always include a prompt field in the parameter file, so that the
GUI can provide a tool-tip for the parameter. The prompt should
be concise and should include units (where applicable) but not
the allowable range of the parameter. Prompts should not start
with a verb (e.g. use Radius (m) instead of Enter radius (m)).
- Always provide a layout file, rather than relying on the default
layout.
- Use tab cards to organize a complex dialog
into a set of pages. The pages should reflect some logical grouping;
related parameters should not appear on different
cards, since they
are not visible at the same time.
- Use tab cards within other layout
constructs sparsely.
Tab cards should be used to break the dialog up into a set of pages.
- Use labeled frames to group together a set
of related parameters, with a label.
- Use enabled frames where part of the
processing is optional. By disabling entry of the associated parameters,
it is clear to the user when the parameters are not relevant.
- Use choice frames when there are a set
of alternative processing options, which require different parameters.
The alternatives imply that parameters are not used by the task when
they are not visible, unlike tab cards where parameters are
used even when they are not visible.
- The logic for reading optional parameters in the task, must match the
nested structure of enabled frames and choice frames, so that parameters
are only used when they are enabled. It is a good idea to read all
parameters in a single section of code, so that the logical structure
is clear.
- Indent nested constructs in the layout file, so that the structure
is clear.
- It is possible to nest layout constructs to any depth. However, avoid
making dialogs too complicated.
XMM-Newton SOC/SSC -- 2003-01-13