Known Problems
-
The default values for the "min" and "max" entryfields in the Motion View
are 1 and 100 respectively. These are not stored as part of the GUI state
in source files, so you must manually set them again whenever you load
a source file.
-
The "progress" indicator in the Motion View grows in proportion to the
difference between "min" and "max". This appears to be a problem with the
underlying Megawidget.
-
In the Motion View, an attempt to "Revisit" a frame that has not been fixed
results in errors that are not informative. This button is actually redundant
as the "<<" and ">>" buttons provide the functionality.
-
Currently, TSIPP is only available statically linked into wish (tksipp)
or tclsh (tsipp). The complicates the distribution process, and means that
users cannot incorporate the widgets they have created into their programs
without changing their interpreter.
-
With tksipp, unlike wish, if the window manager exit button is used then
the program does not exit cleanly but generates a core dump and the message:
called Tcl_FindHashEntry on deleted table
Aborted (core dumped)
TSIPPwb does not provide an exit button, so this is unavoidable.
-
Applications requiring random access to frames rather than playing them
in sequence will experience delays in selecting frames as the RLE file
must be read to that frame either from the current position if this is
earlier, or otherwise from the beginning of the file. This is accelerated
as much as possible by copying the unwanted frames to /dev/null. However,
an RLEseek command is wanted here.
-
Tcl expressions should be bracketed where possible. This has not been done.
-
An application cannot find out the number of frames in an RLE file. RLE
files support comments which could be used for this.
-
Saving an image as a PBM file requires that it be rendered again, even
if it is visible on the screen. This is unnecessary as the rendered image
can be kept in a pixmap. However, this was made more complicated due to
the solution implemented for another problem. It was found that a rendering
line image to a pixmap resulted in a core dump, so these are rendered to
the RLE file and the Perspective View canvas separately, and not to a pixmap.
-
TSIPP uses the terms "Block" and "Ellipsoid", while TSIPPwb uses the terms
"Cuboid" and "Ellipsoid". Since TSIPPwb users are intended to have visibility
of TSIPP documentation, and may well wish to access TSIPP directly as well
as through TSIPPwb, consistency is desirable.
-
When items are selected in the orthogonal views, they are automatically
selected in the Shader/Light view, but not vice-versa. Therefore the selections
can be made inconsistent by changing it in the Shader/Light view last,
which is a confusing state.
-
Cylinders can be edited so that they have different dimensions in the axes
orthogonal to the axis, which should not be possible. The mean of
the two dimensions is actually used as the diameter of the rendered result.
-
The representation of cylinders in the Orthogonal views gives no indication
of which direction is the axis.
Planned Future Enhancements
-
Reduce the footprint of the GUI by collapsing many of the views into a
"tabbed notebook", or exporting them as separate "top levels" which can
be managed by the window manager. This will support low resolution monitors
and individual views to be larger.
-
Greater integration with the GIMP; possibly making it a GIMP plug
in.
-
Add context-sensitive on-line (balloon) help.
-
It is planned to make the MultiView, VisualEdit, MotionEdit and GlobalEdit
widgets true MegaWidgets, and to further increase their independence and
usability for other applications than TSIPPwb.
-
Make all TSIPP features available. Features not yet available include the
grouping of objects together into hierarchies, directional lights, aborting
rendering operations, showBackFaces, Prisms, Torus, Bezier Curves, Texture
Mapping options, multiple cameras, SippLineColor, global scaling so that
the planet shader is useful.
-
Need higher speed playback, exploiting graphics hardware, or 'C' implementation
of the display of the RLE files.
-
Need to be able to find the position of objects in the rendered image,
so that text can be attached to objects, to embed widgets in the image,
so that interactive widget behavior, rather than just display is possible.
-
Divergence handles to be visually differentiated from vertex handles.
-
Some code could be implemented in 'C', for example the rotation and handle
motion routines, to make the interactive response snappier.
-
Implement side handles (one-dimensional motion) on the mid-point of sides.
-
Shaders and lights should have a textual tag as an alternative to their
object names shown in the listbox of the Shader/Light view.