Proposed CCP4i Plugins

Peter Briggs 22nd December 2006

This document outlines the ideas underlying "plugin modules" for CCP4i, which would allow CCP4i to invoke external applications in a variety of different contexts.

Functionality seen from the user perspective

A concrete example of this would be to provide a way to launch a relevant application from the "View Files From Job" menu for specific tasks. The example that is typically cited is that the user would see additional options in the menu for a Refmac job that would allow Coot or CCP4mg to be launched with the appropriate files to see the results of the refinement - see the figure for an indication of how this might appear to the user:

In this example, upon selecting the "View files in Coot" option, CCP4i would invoke the appropriate command for launching the program as a background process, e.g.:

exec /home/pjx/CCP4_CVS/ccp4/bin/coot --no-state-script \
     --pdb /home/pjx/PROJECTS/myProject/toxd_refmac1.pdb \
     --auto /home/pjx/PROJECTS/myProject/toxd_refmac1.mtz &

Some ideas on how to achieve this

The core change required to implement this in CCP4i is to modify the existing DbViewJobMenu procedure (in the database.tcl file). This procedure is responsible for generating the menu that is drawn when the user selects a job and then clicks on "View Files From Job". Additional code could be added of the form:

  # Acquire taskname and look for plugins
  set taskname [DbGetJobData $job_id TASKNAME]
  set plugins [GetPlugins $taskname $filelist]
  foreach plugin $plugins {
      puts "Adding [lindex $plugin 0]: [lindex $plugin 1]"
      $mm add command -label "[lindex $plugin 0]" \
	  -font $configure(FONT_REGULAR) \
	  -command "[lindex $plugin 1]"
  }

which would add additional menu items for each of the "plugins" found.

A new procedure GetPlugins would contain the new code that would look up possible external applications based on the name of the task, the list of files (here only the output files are sent to GetPlugins) and the availability of the applications.

The GetPlugins procedure would return a list of plugins giving the text that should appear in the menu, and the command to be executed when the plugin option is selected, for example:

{ "View results in Coot" { exec /home/pjx/CCP4_CVS/ccp4/bin/coot --no-state-script ... } }

The remaining work is to implement the GetPlugins procedure. The simplest way to implement this would be to hard-code custom checks on the taskname and file list for every possible application. This would be relatively inflexible but has the merits of being quick to add. So it would be worth considering this approach as a first step.

A more extensible approach would provide a more generic mechanism that allowed CCP4i to be configured at runtime, either through a data file containing the necessary information for each of the applications or by sourcing additional files that could be dropped into the distribution.

In either case the user might also wish to have some control over which plugins are presented to them by CCP4i, with the provision of some configuration or preference options.

The level of generality required depends on a number of factors. The key ones that I can think of now are:

• How many external programs would we want to make accessible in this way?
• For each of these programs, in what circumstances would we wish to launch them?
• How much configuration would be required for each mode?

Possible plugin candidates

The table below lists the candidates for plugins so far considered; please let me know of any other possibilities that I can add here.

Additional Suggestions

From Francois Remacle:

• It might sounds extreme, but I guess that each time there is a pdb or cif file in the output there should be the possibility of opening it with mg...

From Ronan Keegan:

• It could be used in MrBUMP to look at the various models that are produced after the model preparation stage and before MR. This is something I know Eleanor was interested in at least. I think she wanted to be able to hand edit the models before MR. I guess this could be done using Coot.

From Kevin Cowtan:

• Very good idea, long overdue.

  Not just refmac. Anything with produces an XYZOUT should have an option to launch a graphics program.

  In an ideal world, a program which makes an MTZOUT should also be able to define a pair of output column names as map coefficients (and maybe diff-map coeffs too). If this definition is in place, then the laucher should also procude a map/maps.

From Paul Emsley:

• I have some thoughts

  1) Great!
  2) I agree with Francois.
  3)I don't understand this gotcha: Need to be able to distinguish dictionary CIF from data harvesting output CIF
  4) Instead of running no script at all, how about letting user make/use a "go-to-my-active-site.scm" script?
  5) Do we care that this could launch n (4,5 etc) different coot processes? Is it reasonable that people would want to "View Results in Coot" for different refinements? It is reasonable to expect users to have mg/coot already open (isn't it?). In such a case, wouldn't the "Right Thing" to do be to send a message to mg/coot that says "open this file", i.e. it should work like URLs do for web browsers - they open up in the running browser, not start a new one (unless a browser is not already running). I can imagine that this is non-trivial. Is this running before walking?

From Liz Potterton:

• From my point of view (ie ccp4mg) there are a couple of areas that need discussion:

  I think firing up MG from ccp4i and defining what you want displayed is easy - maintaining communication to ccp4i or other processes, if that is required, may require a little work - basically this is allowing the other process to update mg or mg to send the other process some result.