A couple months ago, this was something I believed I would never say about the Freehand Drawing Library. Now, the library is and always will be a drawing library. Editing is not part of the core library architecture, however, it is something that requires a level of support inside the library. In the past, this was accomplished by caching the sequence of mouse motions used to define a stroke. The points could be edited and manually assigned to a stroke, either all at once or in an ENTER_FRAME event to animate the stroke.
This works cleanly with a simple interface for typical strokes, i.e. touch-move-release motions. Now that the FDL supports splines and possibly other constructs that stretch the definition of a stroke, what about editing more complex drawings? I want to maintain a light interface and not make editing operations an integral part of the library. That inevitably leads to interface and code bloat in an attempt to satisfy every possible combination of customer-created editor.
I think it was the movie ‘War Games’ that popularized the phrase, ‘always leave yourself a back door.’ The back door to stroke manipulation outside normal FDL methods is to use arbitrary name-value parameters. Every stroke has the ability to access or mutate arbitrary data objects. It’s only two methods in the API, but they provide a wide variety of capability to custom strokes.
I added a simple spline editor to the PolyLine demo as an illustration. After creating a spline (by clicking the end button), the knot/tangent display is overlaid on top of the stroke as shown below.
The spline knots are already available since they were manually assigned to the stroke. The tangent information is entirely encapsulated inside the drawing engine, inside the stroke. That information is obtained by the demo via a parameter request,
__stroke.getParam( “tangent” + i.toString() );
It is the responsibility of each stroke class to document all custom parameter queries and settings. The above query returns in- and out-tangent values in an Object and that information is passed to the editor. Knots may be dragged, which cause a parallel shift in the tangent. The new knot and tangent information is conveyed back to the stroke with a sequence of parameter settings,
__stroke.params = { “changeKnot”:{vertex:index, x:editor.knotX, y:editor.knotY} };
or
__stroke.params = { “changeInTangent”:{vertex:index, x:editor.inTangentX, y:editor.inTangentY} };
__stroke.params = { “changeOutTangent”:{vertex:index, x:editor.outTangentX, y:editor.outTangentY} };
If a spline drawing engine is assigned to the PolyLine, it passes this information onto the internal FDLIntepolatingSpline instance. A non-spline engine (line segments) ignores the parameters.
The screenshot below shows the result of a knot drag.
After dragging the middle vertex, the following screenshot shows the result of editing the first-vertex out-tangent.
This is all supported by the existing architecture, but there is one wrinkle. If the edited spline is to be saved and then redrawn at a future time, we must have the facility to record the tangent edits *and* bypass the tangent Command when the spline is reconstructed.
I added an auxData parameter to the StrokeDataVO, which allows arbitrary auxiliary data to be recorded for a stroke. It’s easy to deep-copy an Object with a ByteArray, so preserving immutability was no problem. Now, by adding support for a ‘redraw’ parameter in the PolyLine stroke, the spline can be redrawn with arbitrary tangents supplied by external data instead of the tangents computed by the injected tangent Command.
The Algorithmist 