What's Missing from COGENT Version 2?

As COGENT has developed we have come to realise that we could go on forever adding features. Version 1.0 was supposed to be an attempt to draw a line under the list of possible enhancements and produce something stable. Development continued, however, and now where on Version 2.0. This appendix briefly describes a number of features that have been suggested by users and developers, and that we are considering including in later versions of the system. These ``wishes'' are broadly divided into three categories: difficult, straightforward, and unknown. The difficult ones will require a substantial amount of thought, and are unlikely in the short term. The straightforward ones are generally simple and will probably get done at some stage --- it's really just a matter of someone getting round to them. The remainder are hard to categorise because though we know what we want to do, we don't at present have the knowledge (of C, GTK, Unix, or Windows) to do it. Hopefully this category will disappear with time.

Within the lists, items are, where possible, presented in order of priority or likely completion. Initials refer to people mentioned in the acknowledgements. We would be most grateful for any further (constructive and realistic) suggestions.

Features to be Implemented Shortly

  1. Document user defined properties.
  2. The property view of compounds (first introduced in version 1.09.00) should be extended to allow setting of properties (rather than just viewing of property values).
  3. In the compound properties view, it should be possible to selective show/hide properties of specified boxes.
  4. Allow copying of a complete model between projects (or cut and paste of models between projects).
  5. The numbers on ignored rules are currently automatically set to zero when a rule is ignored, and reset when the rule is reinstated. It would probably be better to let ignored rules keep their "natural" numbers.
  6. When a syntax error is detected, the user should be given the chance to approve any suggested correction. (First suggested by RC during 11/96.)

Potential Features Presenting no Substantive Difficulties

  1. Make object names on the message matrix sensitive to mouse clicks.
  2. Make external boxes on compound canvases sensitive to mouse clicks (in the way that they were in WinCOGENT).
  3. Allow positioning of external boxes on compound canvases. (First suggested by ME on 30/09/96, but always possible in WinCOGENT.)
  4. Allow repositioning of objects in the project window. (First suggested by JF on 03/04/96.)
  5. Allow rubber-banding of boxes on compound canvases so that they may be coerced into a compound, or to promoted out of a compound.
  6. Install keyboard accelerators for most (all?) functions.
  7. Allow cut and paste and drag and drop between text fields within the element editors.
  8. Reduce the palette by showing only major box classes, and making subclasses appear only when a major class is selected.
  9. Allow summarising of selected rules.
  10. Provide special display facilities for vectors.
  11. Allow selection of multiple elements within a box, so that functions such as ignore, reinstate or delete can be applied to several elements at once. (First suggested by GM during 09/96.)
  12. Allow auto-page of the message log and output trace during execution (only if they are showing the last page of output).
  13. Provide further box classes, such as tree structured buffers, multi-layer networks, and recurrent networks.
  14. Read class information from a configuration file. [It should be possible for that file to be configured by the user to yield appropriate behaviour in non-psychological domains. Thus, one configuration should yield PsyCOGENT. Another should yield BioCOGENT.]
  15. Remove the current dependency on Prolog by re-implementing OOS in C.

Potential Features Requiring Additional GTK Knowledge

  1. Cut down on the screen redrawing when ignoring/reinstating rules.
  2. Ensure that the background colour is used to repaint behind boxes when they are moved. (First suggested by DG on 18/05/98.)
  3. Postscript and HTML output of analogue buffers should be in colour (and HTML output should not use the XBM image format).

Potential Features Requiring Additional Unix/Windows Knowledge

  1. Allow export and import to and from a specified text editor. (First suggested by JF during 11/96.)

Potential Features Requiring Additional Thinking

  1. Some kind of data dictionary/library would be very useful. This should allow terms to be declared and then perform some simple type checking on all terms.
  2. It should be possible to declare new classes (as subclasses of existing classes) and use instances of those classes in the usual way.
  3. Let the user view an animated version of a compound, so that updates and messages show as some sort of flash on the diagram. (First suggested by JF during 11/96.)
  4. Rethink the scripting language (which allows the user to automate lengthy sequences of trials and blocks) so that it uses language and principles more properly anchored in experimental psychology.
  5. Automate the exploration of a property spaces (i.e., automate criticality/sensitivity tests).
  6. Integrate appropriate window management functionality into the basic system (e.g., provide a small model structure-tree so that the user can automatically expand all/some of the model and jump around the modules without getting lost). (First suggested by JF during 11/96.)
  7. Add support mechanisms for data files (e.g., sharing data sources across models within a project, and saving different runs in different files). This may just be a matter of 1) allowing files to be attached to data sources and data sinks (very easy) and 2) providing appropriate browsing tools for those files (harder).
  8. Allow the user to specialise modules (e.g., to specify a standard subject-experimenter compound). (First suggested by JF 11/96.)
  9. Allow isolated running of compound boxes.
  10. Allow save/restore of buffer and network contents, so that training sessions can be separated from testing sessions. (First suggested by GM 09/96.)
  11. Introduce a "Unix/Windows process" box type, whose content is an arbitrary Unix/Windows process (e.g. a C program).