There are only a limited number of hacking months in the year. We need to set priorities for Gargoyle. What are the goals? Which goals are the most important? What are the steps to accomplishing each goal?
Goal 1: Release Gargoyle as a Useful Illustration Tool
Step 1: Easy Text Entry -- Done, KAP February 28, 1986 in .5 days
What: We have a caret, for crying out loud. Why can't we just type?
Priority: Moderate
Estimated Time: .5 days DONE IN .5 DAYS
Step 2: Faster Refresh
What: On even moderately complicated scenes, the user must wait seconds (!) before: (1) an Add or Dragging operation will begin, (2) alignment lines appear, (3) selection feedback appears. Each of these problems requires its own solution.
(1) Add or Drag operations wait for a new background bitmap to be made. Three speedups are obvious: First, use a tighter bounding box for selected objects (currently the bounding box of the whole trajectory is used even when a single joint is to move). Second, allow the picture to degrade -- just clear the boundbox to white and worry about it later. We have been winning the battle of keeping the image perfect, but losing the battle of making a useable interactive system. Third, only show the caret during dragging. Move the object later.
Estimated Time: 1.5 days (DONE took 2 days)
(2) Alignment lines can be rendered in advance. If we go with a scheme where the alignment lines are always showing, we will have to render in advance anyway. A circle cache can be made.
Estimated Time: 2.0 days for render in advance (including debugging). Another 1.5 days for a circle cache.
(3) Selection feedback can be drawn on top of everything (in its own virtual bit plane), so no scene redrawing should be done just to show what is selected. When a large number of objects are selected, Gargoyle can use a light-weight selection feedback scheme (e.g. highlight one joint per trajectory).
Estimated Time: 2.0 days (including debugging). (DONE took 1 day)
Priority: High
Step 3: Splines
What: Why can I only move the control points of arcs? Unfortunately, moving control points of curves with more than one control point per segment will require yet another visit to the sequence and selection machinery. Eric thinks he knows what has to be done, but its not a quick hack.
Estimated Time: 3.0 days (including debugging). (DONE took 2 days)
Priority: Moderate
Step 4: Easy Ways for Easy Things
What: To get a simple box, I have to turn on two kinds of alignment lines, make joints hot, use CaretPos, AddLine, and Close Trajectory commands. To resize the box, I need to know how to select a segment, drag by a joint, while the appropriate alignments are on, and even then, I don't get the same control as I get in Smalltalk. To make a arrowhead, I need both alignment lines and alignment circles.
Provide rectangles as push-button primitives. No easy fix for resize. Provide arrowheads as style parameters.
Estimated Time: 2.0 days (including debugging) for boxes and arrowheads, but the more general goal could take months.
Priority: Moderate (Slice classes and Box class done took 4/5 days)
Step 5: Compute Traj-Traj Intersections
What: Gargoyle gives the user a choice between using light and airy alignment objects or constructing a shape by putting down persistent scene objects. His decision of which to use should not be affected by the implementation detail that alignment-alignment intersections are computed but trajectory-trajectory intersections are not.
Estimated Time: 3.0 days (including debugging), maybe less. To be reasonably fast, this may require computing intersections on the fly. I will try it first without, however. (I have started on this -- Eric)
Priority: High
Step 6: Interim Solution to the Structure Problem
What: If two trajectories "share" a common edge (i.e. the two segments are superimposed), there is no easy way to select the one you want. Any solution requires noticing the ambiguity in the first place. This will require making the gravity machinery return a list of closest objects instead of the single closest. An interim solution would allow the user to cycle through the possibilities, highlighting the whole trajectory belonging to each segment, so the user can tell which he's currently got. Now that the faster selection refresh is implemented (step 2 part 3), this won't be too hard.
Work-around. Build your trajectory off to the side and then snap it onto other things.
The non-interim solution is the subject of goal 4.
Estimated Time: 3.0 days (including debugging), maybe less. (Took 3 days just for multiple gravity. It will take 2 more to get it all wired in and working.)
Priority: Moderate
Step 7: A General Copying Mechanism
What: We can only copy trajectories. The plan is to be able to copy whatever is selected.
Estimated Time: 1.0 days (including debugging), maybe more.
Priority: Moderate -- (DONE for trajectories in 2 hours. DONE for Slices .) Still needs to move the copy instead of the original.
Step 8: Beginning to Drag
What: When you begin to drag an object, you usually want to drag it by a joint or (more rarely) by the middle of a segment. Unfortunately, there is no way to tell if you have succeeded. You might have left gravity turned off, of the gravity extent too small, or wiggled the mouse, or who knows? Possible solution: The position of the caret relative to the selected objects just before the mouse click that begins dragging will be maintained during dragging. Since making a selection forces the caret to sit on a joint of the selected object, this will make the common case work better. If you don't like what happened during selection, you can either reselect (as in Star), or perform a CaretPos operation (with all its helpful feedback) to get the caret where you want it. Then drag. It would also be nice to have graphical feedback telling you what you are snapping on to, instead of a piece of text saying "joint".
Estimated Time: 1.0 days (including debugging), for the basic solution. More for the graphical feedback.
Priority: Moderate
Step 9: Reliable Line Drawing
What: There is an aliasing problem in the Imager. 45 degree lines (and sometimes others) don't always appear. Michael suggests we create our own stipple pattern and test for these as a special case. To make matters worse, the bug might not be in the Imager. It might be in the routine GGLines.LineRayMeetsBox, which is called by GGShapesImpl.DrawLine to clip alignment lines to the viewing box.
Estimated Time: 1.0 days (including debugging), maybe more. ( sort of DONE; new stipple pattern fails far less often. Any stipple/constant color may fail for some angles ??)
( sort of DONE; newer stipple pattern doesn't fail. There is a bug in GGLines.LineRayMeetsBox or GGLines.EvalRay that returns a degenerate line. This causes Box selection feedback to fail sometimes. FIXED)
Priority: Moderate
Step 10: Color
What: There is no way to make colored objects. This is easy to fix, by telling Gargoyle how to take colors from the ColorTool. There is no way to display colored objects. This is more serious. Our double-buffering refresh makes this impossible. However, we can add a special paint command which draws the objects straight to the screen, and does something fairly efficient when the color of a small objects is changed.
Estimated Time: 0.5 days to add color tool, 1.5 days to build a color mode.
Priority: Moderate DONE. KAP. 1 day
Total Time to Reach This Goal: 22.5 days (about 3 weeks)
Goal 1 Progress Report, June 17, 1986 -- Bier
Steps 2.2, 4, 5, 6, 7, and 8 still need work before release in July. This involves:
2.2. Rendering alignment lines in advance. Could be done by Eric or Ken. 2.0 days.
4. Arrowheads. Anyone. 2.0 days (including updates to file format).
5. Traj-Traj intersections. Eric. 4.0 days.
6. Cycling through possibly-hit objects. Eric and Ken. 2.0 days.
7. Copy and Drag. Requires overcoming a selection hurdle. Eric and Ken. 2.0 days.
8. Beginning to Drag. Modifications to StartDrag, StartRotate, and StartScale. 1.0 days.
Total time: 13.0 heavy hacking days.
Goal 1.5 Progress Report, June 17, 1986 -- Bier
Steps 2, 9, 10, 11, 13, 20, 21, 22, 23, and 24 still need work.
2. Outlines as Slices. Eric. 2.0 days.
9. Spline control points. Ken and David. 3.0 days.
10. Update the Refresh code to think in terms of what has changed, rather than what must be done. Eric and Ken. 1.0 days.
11. Polish GGObjects interface. Everyone. 1.0 days.
13. Move selection functionality into GGObjects. 2.5 days.
20. Feedback to show what's hot. Eric and Ken. 1.0 days.
21. Control points can trigger alignment objects. Eric and Ken. 1.0 days.
22. Circle and Disk conversion. Ken and David. 2.0 days.
23. Slices should be given the option of placing the caret on a vertex after segment. Eric and Ken. 0.5 days.
24. Box Slices should allow arbitrary collections of their joints and segments to be selected (and thus to be made hot). Ken and David. 0.5 days.
Total Time: 14.5 man days.
Overal total until release: 27.5 days.
Total work days until release date (July 7): 15 days.
Goal 1.5: Spring Cleaning
In our mad dash to accomplish Goal 1, we have left a number of bugs around, muddied the architecture, and left unreleased some things that the world ought to have (see Goal 3). Here is a top-of-the-head checklist:
1) Rename Cluster => Slice (DONE, Bier May 28, 1986)
2) Make Outlines Behave as Slices
3) Add Radius puts the new radius in the wrong place. (DONE)
4) SlackProcess should MONITOR the queue RECORD so we can have multiple queues. We will use this to have a real painting queue. (DONE)
5) Rick Beach has fixed TiogaButtons so that the first button can be removed. We should track that change. (DONE)
6) Rename gravity-sensitive to gravity-active to track the paper. (DONE)
7) All Slices (Clusters) should be able to trigger alignment lines. (DONE)
9) Finish implementing control points for all of the spline classes. (Conics Done)
10) Update the Refresh code to think in terms of what has changed, rather than what must be done.
11) Complete the GGObjects interface and polish it until it shines.
12) Allow Box Slices (Clusters) to change line width properly. (DONE)
13) Get rid of GGInterface.mesa by adding its selection functionality to GGObjects.mesa.
14) Provide "None" as a possible fill color. (DONE)
15) TIP Table: I would be happier if Double-Left was SelectTopLevel, and Double-Middle was SelectTraj, instead of vice-versa (DONE). We should be consistent about Select and Extend. We can select a text slice with Joint select, but we can't extend to one.
16) Area Color: Call it "Fill" (DONE). Allow the option "None". (DONE)
17) Cursor shape should change as soon as the gravity parameters change, not at the next mouse motion. (DONE).
18) Midpoints should be computed for all segments, not just those which are hot. (DONE)
19) Maybe use slice gravity mechanism to return midpoints as well as closest points/segs.
20) Feedback to show what's hot.
21) Control points can trigger alignment objects.
The Slope/Angle field should become two fields, one reporting the slope between the last two points, and one reporting the angle between the last three. (DONE)
An "Angles" line should be added after the "Distance" line. Like the other three, it should have Add, and Get buttons and should be implemented with TiogaButtons. -120, -90, 0, 90, 120 are reasonable defaults. (DONE)
The Transforms Menu should be fleshed out. The operations Scale, Rotate, TranslateX, and TranslateY should be added. Each of these takes the current text selection (which should represent a REAL number) and transforms all selected objects by that transformation. Scale and Rotate should both use the Anchor as the center of scaling and rotation. ScaleX, and ScaleY should be fixed to do this as well. These operations should work on Slices and Sequences both. (DONE)
22) The Circle and Disk Segments classes should go away. A single Circle Slice class should be created. A Menu should be added (Pop up I think) listing predefined shapes, such as Circles, Squares, Equilateral Triangles, and so on. When the button is pressed, and object of that type is created at the caret position
23) Slices should be given the option of placing the caret on a vertex after segment select, just the way trajectories do. This may require a NearestJoint SliceClass Proc.
24) Box Slices should allow arbitrary collections of their joints and segments to be selected (and thus to be made hot). ALMOST DONE. NEEDS CHANGE TO CLASS STUFF.