You are currently viewing a snapshot of taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to, please file a bug.

Vixen Design Specifications

VFD XUL File Loading

Files are loaded into a XUL IFRAME in a template window. This template window is created for each XUL Visual Form Designer (VFD) open. No special analysis is required.

On document load, all unitialised UI elements related to an unselected VFD are updated, including the DOM Tree view

VFD XUL File Saving

The DOM is serialised, and invisibles such as stylesheets, overlays and dtds are merged, and the output is written to disk.

Note: It is possible that XMLExtras could be used for this although we require the ability to write pre-processor directives, DTD includes etc., and readable formatting is also highly desirable. As a result it is likely that we will have to produce our own solution.

Node Insertion Commands

The various element insertion options are all routed through generic node insertion and attribute setting routines. At the highest level, each element type has a command for an insertion of a node of that type. This command maps to a JS routine that calls into a modified version of generic DOM APIs. These modified APIs will probably exist in a C++ VFD shell so that interaction with editor's Transaction Manager (TXMGR) is possible. When an element is inserted, removed, attribute changed etc, record of that change is made in the form of a Transformation, which is pushed onto the txmgr's do stack so that unlimited undo/redo is possible.

A document will be produced containing a list of all the insertable elements and their mapping to commands.

Visual Representation of Active Nodes

Most user interface elements allow user interaction of some form. Text fields are editable, buttons are clickable, and so on. In the VFD, much of this behaviour is undesirable, and we certainly do not want user-specified events to fire on elements. We will need to devise a means to prevent events like oncommand firing on buttons, even when the user has specified a handler. Menus will need to be taught to not close automatically (rather, they will have to be clicked closed as they are clicked open). This will involve a number of small patches to various widgets to give them an 'edit mode' in which their standard behaviour is reduced.


In the VFD, almost everything can take focus. Focus needs to be indicated not in the conventional sense, but in the sense that the focused element is selected. Selection of leaf nodes (e.g. button) implies that a new element will be inserted into an adjacent position. Selection of container nodes implies that a new element will be inserted as a child of the selected node. We should also support multiple selection. In the case of multiple selection, node insertion will be disabled but the user will be allowed to delete the selected nodes if structurally possible (cannot delete any required components of a grid or tree, for example). Should be possible to select boxes, grids, grid rows and columns, and individual cells (components).