Design notes

Liftplan Implementation

Basically the only difference between liftplan and treadle drafts is the constraint for a single treadle selection in normal drafts is lifted. It also constrains the treadle plan to be a simple diagonal. The original code bakes in the assumption of not-liftplan in a few places that need to be changed in order to implement liftplan. Also the name "Treadle" will become a little inappropriate in some places but I might just live with that.
- WeftPick has a single treadleId field that will have to be made a collection.
- and therefore setTreadleId will not be appropriate. Probably not getTreadleId either.
- Draft Properties window needs a checkbox to select liftplan, which will disable the number of treadles.
- WIF IO needs to handle reading liftplan WIF
- WeavingDraft sets the tie-up to be a single diagonally. TieUpModel does not permit that to be changed when the draft is Liftplan.

Improved Paste

Sharing the selection between the two grids means having an object to represent the selection. It makes sense for that to be the thing that does transforms on the selection (stretch, reflect etc). But where does it live? It seems to be a property of the session. Persisting it seems wrong. It needs to be visible to either the grid model or the grid view to implement pasting; probably the model. Copying could be implemented with an event but I can't see how to do paste with events. Paste should implemented by the grid model, and selection buffer definitely originates there. Using the window to mediate would be ugly and anyway wouldn't help because the GridControls sit between. An EventAggregator might help but something still has to pass that object to where it needs to be, unless we use a singleton.

The session is created by the WeavingSimulatorApp but immediately passed to the WeavingDraftWindow to be owned. Reasonable enough, there can be multiple sessions with a window on each. So with a little refactoring, the two grid models in question can see the session. There seems to be two selection concepts here: the thing that can be pasted, and the cells that are highlighted on the screen. probably need to separate those. Can we stop displaying the selection at click-away? Seems like normal behaviour.
- Do drag: view tells the model to show selection
- End drag: view tells model to set selection. Model tells session the selection.
- Click (possibly outside view): view tells model to clear selection.
- Click->menu->paste: view tell model to paste. Model asks session for selection.

Undo

It is well known that Undo is generally implemented with Command pattern objects held in two queues. Editing Session is the obvious place for those queues. The problem is, nothing so far uses command objects. I wouldn't start from here. So it looks like we need to
- Create a command interface
- Put the queues and appropriate methods on the Editing session. do(command), undo(), redo() I suppose.
- Mediate all actions that the weaving grid models do to the Draft through the Session. This may not be too hard as most of the models use a Session now after the copy/paste work.

How does the command work? It should be able to know which elements of the draft it is setting, so it can record the state before to restore it. Its interface has do and undo methods. The object is bound to its target at construction. What commands are there:
1. Set the harnesses of ends
2. Set the treadles of picks
3. set tie-ups
4. Set draft properties.
5. Set Pick colour
6. Set End colour
7. Modify palette

The first three are the most important, it will be nice to support the rest too.