Table of Contents

Object Manager

Quick Contents of this Page

Overview of the object manager

When an object is selected for experimentation, its icon appears on the screen with a pop-up menu of tools (Figure 1). The program which produces the icon and handles the menu selections is called the
object manager and is invoked when the user places an object on the lab table.

Figure 1 - An object icon with menus

The object manager performs the following tasks:

The tools associated with the object are defined in two files: the object's specifications file, and the generic tools file residing in the vlab config directory.

Specifications file format

The specifications file serves three purposes:

Selecting a menu item allows the user to apply a tool to the object as a whole, without detailed knowledge of the program or the component files involved. An example specifications file is given in Figure 2.


tree.l
tree.v
panel.v
tree.ras
text
*
image:
        generate:
                cpfg  tree.l tree.v 
        snap:
                snap tree.ras
        paste:
                ipaste tree.ras

text:
        TEXT text

; this is a comment 

Figure 2 - A sample specifications file

The first section, terminated with a single asterisk on a new line, lists all the files associated with the object, one per line. Two additional files are assumed to be included in every object: the icon file (see the icon display in Figure 1), and the specifications file itself.
A menu description follows. It specifies each menu item, using tabs to indicate successive levels in the menu hierarchy and colons to terminate the entries. Menu items must not contain spaces. For example, the menu hierarchy shown in Figure 1 was created using the specifications file in Figure 2 . Each menu item is either followed by a sub-menu item or by an executable UNIX command. Thus, according to Figure 2, selection of the item image followed by the item generate from the menus invokes the plant modeling program cpfg with the argument data files tree.l and tree.v .

The generic name, TEXT, is assumed to have been defined in the tools file, which describes tools commonly used in the virtual laboratory. Thus commonly used tools need to be specified only once, in one system-wide file.

Comments may be inserted in this file. Lines that begin with a semicolon are treated as comments.

Tools file format

The tools file describes generic tools that may be used within an object's specifications file. Entries in the tools file may be accessed by all objects in the virtual laboratory, thus eliminating the need for providing details of commonly used tools in each object. The tools file resides in the vlab config directory. Entries in this file consist of a generic name, plus a list of tools. The list resembles the tool descriptions in the specifications file. Each entry in tools has the following format:

- a generic name for the entry used to identify it in the specifications file (by convention, this name is upper-case),

- a tool name, followed by a colon (this is the name that will appear in the menus of the objects that use this tool)

- the command associated with the tool, preceded by a tab.

Several tools may be associated with a single generic name. Entries must be separated by a blank line. The parameters to be used with the tool are not specified on the command line in the tools file. They will be appended to the command using arguments in the specifications file.

For example, TEXT may be defined as follows:


TEXT
display:
        xless
edit:
        EDITOR
print:
        enscript -Palw3


The above global definition will be substituted for each occurrence of the word TEXT in the specifications file. Such global definitions facilitate customization of the lab for each system configuration.

The tools file may also include comment lines and global definitions.
Comments start with a semicolon followed by any text on the same line. Comment lines may be inserted anywhere in the file.
Global names may be defined using the syntax:

#define SYMBOLNAME definition_string

where definition_string is a UNIX command to execute.

For example:
#define EDITOR emacs -font "-*-courier-medium-r-*-*-14-*-*"

These definitions must occur at the beginning of the file.

Customization

The following procedure can be used to customize the editors used by the object manager.

The first two lines of the tools file define what editors are to be used by default. The names OBJED and OBJDEMOED are reserved and interpreted by the object manager when invoking shells for editing. By default, they are set to the vi editor. OBJED is for regular editing and OBJDEMOED is for editing while performing demos (the font size is bigger). If you wish to use a different editor (such as emacs), change the two lines;


#define OBJED     xwsh -s 80,24 -f Courier-Bold18 -c vi -w24
#define OBJDEMOED xwsh -s 60,12 -f Courier-Bold24 -c vi -w12
for example, like this

#define OBJED     emacs -font "-*-courier-medium-r-*-*-14-*-*"
#define OBJDEMOED emacs -font "-*-courier-medium-r-*-*-18-*-*"

Note that the program you specify must open its own window. Since emacs does, it can be listed as above. Since vi doesn't, the lines must open a shell which then runs the editor.

Note that the names OBJED and OBJDEMOED can be used in the remainder of the tools file like any other names (in particular, they could have been used instead of EDITOR in the previous example).

The Utilities Submenu

In addition to the items defined in the specifications file, the menu displayed by the object manager always includes a Utilities submenu and a Quit item.

The Utilities submenu includes the following menu items:

The Lab Table

The lab table is a temporary directory normally created in /tmp. All files listed in the specifications file are copied to this directory and as tools are selected from the object menu they are applied to these temporary files, leaving the original files untouched. Users may modify parameters and change the object's definition by manipulating the data files in the object on the lab table. New tools, with accompanying data files, may also be added to the object by editing the specifications file.

Before removing the object from the lab table (by selecting Quit from the menu), the user must decide whether the modified object should be permanently stored. It may be stored as a replacement of the original object, or as an extension of that object. If an extension is requested, the user is prompted for its name and a new directory is created in the ext directory of the original object. In both cases, the files on the lab table are compared with the files in the object's prototype. Files that differ from the prototype are copied to the object's directory; the remaining files are created by establishing UNIX symbolic links to the corresponding files in the prototype.

References

L. Mercer. The Virtual laboratory. Master's thesis, University of Regina, Regina, Canada, 1991.

L. Mercer, P. Prusinkiewicz, J. Hanan. The Concept and Design of a Virtual Laboratory. In Graphics Interface '90 Conference proceedings, pages 149-155. Canadian Information Processing Society, 1990.


Credits

L. Mercer, P. Federl - object manager implementation

Selected routines for image manipulation copyright 1994 by John Bradley. Used with permission.

M. James - implementation of the makeicon utility

D. Ratcliffe, P. Haeberli - authors of the snap and ipaste program, parts of their code was incorporated in the makeicon utility. Used with permission.

I. Hernadi, L. Mercer, P. Prusinkiewicz - object manager documentation


Bugs

1. The Copy and Paste commands are not implemented, the Directory items provide similar functionality.

2. Manipulating the object's files "by hand" is possible, but the user must remember to update the specifications file accordingly, otherwise the new files will not be saved with the object.

3. The specifications and tools files must have tabs placed correctly, spaces won't do. The menus will not be created properly if these files contain spaces instead of tabs, and no warning messages are generated. This problem is particularly annoying while using the SGI system-wide "cut and paste" facility, because it replaces tabs with spaces.

4. The Help facility is not yet implemented.


Contact Information

Please direct all feedback, bug reports, and so on to vlab@cpsc.ucalgary.ca.

Last updated Feb. 27, 1996 by Istvan Hernadi