The undo manager can be a pain in the butt! The chaining/aggregation of events had me befuddled for quite a while indeed. Initially I didn't realize that I had to chain the events manually (that the UndoManager wouldn't do it for me if I told it that I wanted a chain). But then when I realized that I had to manually implement the chaining, it made more sense why that was the case. It matters whether the chained events are invoked before or after the current event on undo and redo!
Concerning curved edges, Dondi sent me this interesting SVG sample spline. I think I could incorporate that logic and make a pretty sweet edge. Fortunately I think that I've found a way to intuitively offer the CubicCurve2D as the underlying edge implementation. This way being only allow one edge to be selected for control point manipulation at a time, thus only showing one edge's control points at a time. This will leave no ambiguity as to which edge the control points are for. We'll determine whether this is a decent long-term solution. Previously I had envisioned showing the control points for all edges at the same time. That would have led to a large amount of confusion and ambiguity.
Subscribe to:
Post Comments (Atom)
Actually, I took that for granted (i.e., that only one curve would be selected at a time). Glad you ended up going there anyway :-P
ReplyDeleteAs to the undo manager, yes, architecturally it is quite different from non-undoable code. The Command design pattern is usually the secret to success in this regard. It would be worthwhile to compare what you have to what you can read about the Command design pattern and see how close you got.
Ah, I see you used javax.swing.undo. UndoableEdit does follow the Command design pattern, so that works.
ReplyDelete