DPVC (CV/Research)

There are a number of areas in which StageTools can be improved. Some of these are small changes that can be made as time permits, and others are substantial coding projects that can only be accomplished with large blocks of time. One area that always needs improvement is the documentation. Currently, this consists of a single reference document in text form for each module. These need to be turned into HTML documents for easier use, and more tutorial materials should be included. Of course, many more examples also would help, and they need to be documented better as well.

The user interface for StageTools could be enhanced. The editing features in the script windows need to be improved considerably, for example. Also, the selection lists could be made easier to use: the user should be able to drag object names from one group to another in CenterStage, entry names should be able to be changed by typing into the list, and so on. The relative sizes of the various panels within the windows should be able to be controlled by the user. There needs to be a better font control mechanism.

The error-reporting mechanism, whose shortcomings are discussed in the StageTools document, needs improvement. There are a number of things that could be done to make these more useful to the casual user.

The underlying mechanism for handling linked objects needs to be improved in a number of ways. First, the current approach only allows for an object to link to one other object, but this is too restrictive. For example, it would be nice to be able to define an object class for a ruled surface between two parameterized curves. This is not easy in the current model, since the natural way to do it would be to link it to two different curve objects. Second, more information needs to made available from the linked object. For instance, the linked object should be able to inherit the coloration of the original, when appropriate. That is, the slicing object should be able to produce a slice that is colored the same way the original object was; currently such common coloration has to be maintained by hand. Although this process seems obvious, it is not as clear-cut as one might think, and involves some important abstraction that I have not yet worked out in detail.

While the menu items in CenterStage make it easy for the user to change attributes like the domain style and coloration, they make it harder for the object to control these values programmatically. For example, the domain style might need to change depending on the values entered by a user in an input widget; this is difficult to accomplish currently, since the menu selections can not be changed by the scripts in the definition window. A means of accessing the menu selections from within the object itself needs to be implemented.

In CenterStage, Group objects can be used to restrict the scope of a variable so that changes to that variable don't cause updates to objects that don't really need to be recomputed. This mechanism is not intuitive, nor is it really flexible enough. A better mechanism of determining the update tree is needed. This is quite difficult, and likely will require some major rewriting of the core of CenterStage. Associated with this problem are some other variable-scoping issues inherited from TCL. For example, the statements within the body of the Function in a Surface object have access to the local variables for that object (like the ones associated with sliders) without the need for any special declarations; the body of a procedure created by the proc command, however, does not, which can be a source of confusion and errors.

It would be nice to have CenterStage be able to save objects in formats other than OOGL (Geomview's underlying format). For example, there is a java applet [43] that can display and rotate an object stored in Mathematica's Graphics3D format; if CenterStage could write this format, it would be possible to use CenterStage to create rotatable illustrations for web pages. A more powerful applet [44] that is being used as the basis for an on-line refereed archive of geometric models [45] uses a superior format, which CenterStage could be programmed to support.

A port of CenterStage to java would be a major, but useful, project. It might be possible to replace Geomview by one of the applets mentioned above, and thereby produce a truly dynamic 3D environment on a web page. It may be possible to use student assistants to perform some of the programming for this, though it is too much for a single student.

Davide P. Cervone's web pages Created: 08 Sep 2001 Last modified: 07 Jan 2001 06:11:12 Comments to: dpvc@union.edu

The StageTools Geometry Package Software Development Research Interests An Overview of StageTools