BioLegato internal menu format ideas

From Bioinformatics.Org Wiki

bioLegato: Biolegato Menu Language

Note: We should have a look at menus from other applications to see if there are capabilities that need to be in our menus (OpenOffice, Mozilla, MS-Office, NetBeans)

Contents 1 Biolegato will probably just directly read the menu directory hierarchy, rather than reading a .bioLegatomenus file. 1.1 Advantages 1.2 Disadvantages 2 Moving away from .GDEMenus 3 Need ways of using data from an object in the menu. 4 Conditional display of some parameters? 5 be able to run jar files directly (saves memory) 6 Miscellaneous

Biolegato will probably just directly read the menu directory hierarchy, rather than reading a .bioLegatomenus file.

Advantages

• we get rid of makemenus.py
• easier to maintain; quicker turnaround for development and debugging

Disadvantages

• Are there disadvantages to specifying menus by their location in a directory tree? The early GNOME menus were a pain in the butt for this reason.

Moving away from .GDEMenus

• A more strict grammar than .GDEmenus
  • Specific order for each line for a varialbe
  • Descriptive error-messages to stdout
  • A syntactical distinction between internal bioLegato variables and external environment variables.

eg. $TEXTEDITOR is an environment variable; !TEXTEDITOR! is an internal variable; !IN1! is another

• Should variables be case-insensitive?
• We will need a script that converts the old .GDEmenus files into bioLegato files. This is useful not just because it will speed out progress in converting to the new format, but also, it will give others who have made local .GDEmenus items a chance to convert them as well.

Instead of a script, another way to do this is to add a plugin to bioLegato that reads .GDEmenus as usual, but then writes out the new format.

== Possible multiple help buttons? Have a command like itemopen: to let you choose both the help file and the method to open it. (Should itemopen and itemhelp be combined into a single line?)

Need ways of using data from an object in the menu.

For example, the sequence length should be accessible as a variable within the menu. Two ideas:

• variables can be taken directly from the hash
• a small language for doing manipulations: conditonals, comparisons etc. (Maybe this could all be handled by an external script)

  Beanshell

Conditional display of some parameters?

That is some parameters are irrelevant depending on the settings of others. For example, in DNAPARS, there are four parameters that can are not used if resampling is not done. In GDE, these are offset by five dash characters to make it look like indentation. You can still set these parameters, but they are only used if resampling is done.

One approach is to gray out irrelevant parameters. Another would be to just not have them appear if not used.

be able to run jar files directly (saves memory)

Use plugin code

Miscellaneous

• File chooser
• argvalue is an actual value, rather than a reference?
• Should be human-readable, human-editable ie. NOT XML
• Tabbed panes in menus
• Grouping menu widgets visually in boxes
• Graphics eg. icons in menus
• mouse-over help items
• Sanity checking at the level of the menu (with interactive prompts) This is why we need #7 above.
• Menu parsing should be extendable by means of plugins.
• Right now all scripts run by bioLegato require that all parameters be specified on the command line, regardless of whether or not they are used. This works, but it's a bit crude.
• Need real number arguments