Design pattern for Vector Graphic Editor

Question

What are the best practice design patterns/architectures for vector graphic applications like PowerPoint or Illustrator? Specifically for structuring tool-user interaction and action on complex graphical objects (parent-child relationship, geometrical constraints on shape and layout).

Any thoughts about or experiences with the following:

1. Behavior - Adorner - Behavior Stack/Service - View - View Model Microsoft

2. EditPolicy - EditPart - View - Model GEF

Answer 1

Nested finite state machines for controllers. Separation of view from controllers (MVC or similar). It always worked for me.

Update: I had some time to read up on your links. Some background: I have been studying and working on these types of editors for 25 years. My advice, nested FSMs as controllers, MVC or similar, might be called a super design pattern, because you can see these design components appearing many times over the years, in different designs, each time using different names for the different components. The absurdity of the Microsoft patent is that the ideas are very old, just given new names. If you look at the other link you provided, you can see there are a lot of similarities (EditPart == Behavior == Finite State Machine).

So the super pattern is as follows: nested finite state machines, as in a Harel state chart. Super states handle common behaviors across many sub states; sub states handle more specific behaviors. A super state can be implemented as a super class, or as a separate object instance. In either case, in the overall application, abstractly you have a current state, which is the sub state. If the sub state cannot handle an input message, it goes to the super state (either just using inheritance or by passing the message to another object in a stack).

State transitions are triggered by input messages. An input message might be a user action on an adornment (and an adornment might be decorated the name of a sub state to invoke). Or it might be a keyboard event. You may see an input message called a command.

Every state will have an entry method, whereby it performs initialization, and an exit method, whereby it reverses any changes not committed. Changes are typically committed using transactions, and a stack of committed transactions forms the undo stack.