Changes to the CCP4i Modules & Tasklist Presentation

Peter Briggs 21st December 2006

This document outlines the work that would need to be done to properly implement the proposed changes to the CCP4i modules and tasklists, in order to add "subfolders" within each module.

Current Status

The document outlining the motivation etc behind this is online at http://www.ccp4.ac.uk/peter/ccp4/ccp4i_modules.html.

A demonstration implementation of the changes is in the CCP4 CVS archive, in a branch called ccp4i-dev-2006 (this is just for the $CCP4/ccp4i directory).

To try this version out with an existing installation of CCP4i do the following:

• In a separate area check-out or export the branch:
  % cvs checkout -r ccp4i-dev-2006 ccp4/ccp4i
• Source the setup file for your current CCP4 installation
• Edit the ccp4i-dev.setup script to point CCP4I_TOP to the new ccp4i directory, and then source it.
• Start CCP4i as normal.

Examples of the new-look modules and task list as implemented in this prototype are shown below for the "Molecular Replacement" module. In both cases, the "subfolders" are shown as bars with a grey background and italicised text, and task buttons appear the same as in the current CCP4i version.

In the first example, all the subfolders are in a closed state, so only "top-level" task buttons appear. In the second example, the "AMoRe Suite" subfolder has been opened up and the AMoRe tasks are now visible.

Some of the issues that this prototype raises:

• The task buttons in subfolders have less space for text than those at the top level
• What should the subfolders look like?
• What should the task buttons in the subfolders look like?

These questions concern cosmetic issues and the solutions should not be difficult to implement once a decision has been made.

Random Technical Details For the Prototype

The changes that have been made are to the following files:

• taskbrowser.tcl: updated the taskbrowser procedure to use ReadTaskList_new (original version still available as taskbrowser_orig)
• browser_utils.tcl: new proc ReadTaskList_new which reads module and task data from modules.cfg; new procs open_module_folder, close_module_folder and update_module_scroll for manipulations of the display. New proc update_module_new which updates the displayed tasklist when the user switches between modules.
• read_modules.tcl: new file that contains the code for reading data from the modules.cfg file. This includes a set of Get/Set functions which wrap the contents of the "modules" array used in CCP4i to store the module and tasklist data.
• modules.cfg: new file that gives the information on the arrangement of the modules and tasks. This is a plain text file that used in place of the modules.def file in the prototype.

Work required to make this production-quality

This is a quick sweep through the required changes.

Before coding:

• Decide whether this model is suitable to be implemented fully
• Identify any possible problems/future extensions
• Decide on cosmetic details of look and feel

Areas requiring recoding:

• The modules.def format will have to be extended in order to accommodate the new subfolder ideas; reading and writing functionality in modules_utils.tcl will need to be updated in parallel to accommodate this (including maintaining backward compatibility).
• The CCP4i_packages_utils.tcl functionality will need to be updated to deal with any modifications to the existing functions in modules_utils.tcl, and to access any new functionality required to exploit the new information in modules.def.
• The "Edit tasklist" interface will need to be updated to accommodate the new features in modules.def.
• The "Import/Export" interface will need to be updated to accommodate the new features in modules.def.
• Cosmetic details will need to be implemented (look and feel of buttons and behaviours of subfolders and so on).

Other Relevant Areas That Are Not Part of These Changes

• Task definitions could include an optional additional def file
  The idea is that e.g. a number of different Refmac tasks could be presented that use the same interface, and different only in the starting parameters that are loaded when the user hits the task button. So one task could be "Review Refmac Restraints", which would start the Refmac interface with parameters already selecting "review" options; another task could be "Refmac Restrained Refinment", which would start the same interface with a different set of starting parameters to give "restrained refinement" options by default (and so on).
  This is relevant as