Here is what I have been up to while you were away:

The first week, I worked on the Gargoyle design document for a few days. Steve Wallgren took me to his office to see I Star demo. I went to ISL to get a demo of Richard Burton's Sketch. Both demos were VERY helpful and enlightening (see the Gargoyle notes and suggestions below). Towards the end of the week I got a hack attack and made us a Gargoyle window, an Input Notify Proc, an interim icon, a separate draw process, a dummy menu, a TIP table, our own Container Class, our own Action Area class, a DF file, a config file, and some 2D Vector operations stolen from Solidviews. This involved no real design decisions, and gives us a sheet of paper on which to begin. When next we start coding, we should spend some time reorganizing and tidying up this code, so you can adopt it and love it like your own.

The second week, Ken Sloan was here and I went into gonzo paper rewriting mode (two Solidviews papers). Ken has now taken them off my hands, so I am a Gargoyle elf once more.

Now about this Gargoyle...

Star already encorporates most of our ideas about having a caret and using text editor-like operations. In fact, their caret even looks like a caret. They allow multiple selections, but only one caret. It seems to me that this will solve all of our problems as well. Shift select will be well defined, while dragging operations can include several trajectory segments (and in fact several trajectories, see below) at a time.

Sketch has the idea of clustering, but it is less strict than Griffin. In the first place, a trajectory is not rigid by definition. A trajectory can be made rigid, by clustering it. A trajectory is also rigid when its control points are not displayed. However, there is a mode in Sketch where all unclustered trajectories show their control points (and clusters show a single control point representing their two degrees of translational freedom). Frank notes that Gargoyle will probably have to deal with more complex pictures than Sketch, so having everybody show control points may be a bit much. This sounds reasonable. Why not have a command which shows the control points of a particular trajectory (or cluster) and another which shows them all.

My first big realization while you were gone: All trajectories in Gargoyle are going to display themselves in proper color and line width at "all" times. What I mean is: there is no special state that trajectories get into when they are editable. If a trajectory is showing its control points it is editable. If it is clustered, it will not show its control points. If its control points have been turned off, it will not show its control points. What's more, we're going to rubber-band these things. But it will be too slow you say. No problem. During rubber-banding we will cheat. When rubber-banding is done, we redraw with proper appearance. This simplifies many of our worries. I'm rather excited about it.

My second big realization: We're not doing constraints this summer. We are doing a little topology. We will keep track of which trajectory is touching which other trajectory, and where. I believe trajectory is the correct level at which to do this and that the touching relationship is independent of the clustering hierarchy. We'll see. I'm going to have my hands full thinking about symmetry modes and how they interact. Since constraints are kind of the residue of symmetry modes (and parallel, congruent, horizontal, vertical modes) anyway, I believe we will have enough hooks to add them in later.

A medium-sized realization: Pavel's idea about allowing trajectories to have multiple width and color styles should be pursued, for two reasons. First, it gives the artist some help in overcoming the limitations of the priority ordering. Second, it is a direct analogy with Tioga looks. In particular, when you SHIFT-select one bit of contour into another, the answer to the question "Which trajectory determines the style" is "neither, they both keep their own styles, producing a trajectory with multiple line styles." If you want them all to be the same style, you must select one part or the other and change the style. This is particularly important for spline type, since you clearly don't want one trajectory to adapt the spline style of the other and change shape. It also dove-tails nicely with the idea that visible control points is the only prerequisite for being control-point-editable.

A delicious note: I think we have escaped the problems that Griffin had where the "current style" was changed when the Modify command was used. In Gargoyle, there will be no Modify command, only visible control points. When a new contour is created, it is a polygonal path, until told otherwise. When a new control point is added at the caret, it takes on the style parameters of the adjacent segment. I'm psyched if you are.

The selection hierarchy and the rigidity hierarchy are a little different. Selection: Left bug selects points. Middle bug selects whole trajectories. Double-left-click selects outlines. Double-right-click selects the top-level object containing the selected one. Intermediate nodes are selected (in the rare cases where this is necessary), with a special extend selection command (maybe by n-clicking?). Rigidity: Only clusters are rigid. Trajectories are not rigid. Outlines are not rigid. A cluster contains one or more outlines and clusters.

Holes are made with the AddHole operation which works as follows: Select a fence trajectory (e.g. a lone trajectory, or the fence of an existing outline with holes). Then select any number of lone fence trajectories. Click AddHole! The 2 ... nth arguments become holes in the outline to which the first trajectory belongs. RemoveHole takes n hole arguments and turns them back into lone fences. This operation has an effect on appearance, but not on rigidity.

That's all for tonight. See you tomorrow,

-- Eric