Improved Error Handling

Studio580 is developed as an aggressively factored object-oriented software system. When classes in the system encounter an error that they cannot handle locally, they throw an exception. These exceptions are, in most cases, not caught. This behavior is actually very useful during debugging, since the debug runtime pinpoints source locations from which uncaught exceptions are thrown and prints detailed stack information on the propagation of an exception. From an end-user standpoint however, this behavior is terrible. It means that Studio580 responds to many recoverable errors by simply halting execution instead of attempting recover. In the eyes of the user, Studio580 “just crashes.”

As a result, a near-term development goal is to improve error handling to the point where error handling in Studio580 is treated the same way that it is most modern, graphical applications: through user notification by way of a dialog or message box and an intelligent attempt at recovery.

Improved Brush Dynamics

Studio580’s brush dynamics have known issues. The nature of these issues and strategies to avoid them are discussed at length in the Problems, Annoyances & Workarounds Guide and the Tips & Tricks Guide and so will not be discussed further here. As both of these documents discuss, nearly all of the problems with Studio580’s brush dynamics implementation arise from the fact that Studio580 does not smooth the mouse trajectory that it captures prior to stroke assembly.

As a result, a near-term development goal is to implement a scheme that smoothes the captured mouse trajectories via cubic B-spline interpolation prior to stroke assembly. This feature should be implemented in Studio580 version 1.0 pre-release 9, or earlier.

Improved Brush Packaging

With only one or two brushes installed, Studio580 isn’t a very interesting application. It becomes interesting (and useful) only when its user has an extensive library of brushes at his or her disposal. Users acquire more brushes by creating new brushes themselves, or by installing brushes made by others. To easily install brushes made by others, however, some kind of brush packaging scheme needs to exist. As discussed on page 2 of the Tips & Tricks Guide, Studio580 brushes are most useful when they’re grouped into families of related, subtly transformed variants. Because of this, “installing a brush made by someone else” really means installing five or six brushes made by someone else. But as is described in the Readymade Brush Installation Guide, this entails a lot of clicking, dragging, and selecting, which quickly becomes tedious.

As a result, a medium-term goal is the development of a brush packaging tool that will enable the easy, one-click creation and sharing of packaged families of brushes between Studio580 users.

Configurable Stroke Caps

In its current form, Studio580 can generate strokes having only flat end caps. This is illustrated at far-left and at center-left in the figure below. At far-left is a typical stroke drawn in Studio580; at center-left is a model of the underlying geometry of the stroke. In the model at center-left, the user’s mouse trajectory is shown in blue. Given this mouse trajectory, Studio580 then builds the stroke body, shown in gray, and finally adds end caps to the terminal ends of the stroke. These end caps are shown in green.

But flat caps aren’t the only kinds of stroke caps in widespread use in interactive painting systems. Also widely used are round caps, illustrated at center-right in the figure, and calligraphic caps, shown at far-right. But as noted above, in its current form, Studio580 can render only flat caps.

For this reason, a medium-term development goal is to add configurable cap generation behavior to Studio580, enabling the user to choose interactively among several different cap styles at runtime. Support for adding this feature is already in Studio580, as the code that generates stroke caps is kept separate from the code responsible for the stroke body, in theory enabling snap-in modification.