Are QUndoCommands supposed to be tied to a view or a model?

Question

In Qt's undo framework, you can have a stack of QUndoCommand instances. Each of these describes an action in the user interface. In our application, we have a set of views working on a set of models, some in combination, and we often have more than one view working on the same set of models. I'm now looking at the ability to undo actions based on this framework.

Now, I am familiar with the general pattern of having command classes to describe UI actions, but are these supposed to represent a state change in UI elements, or a data change in the underlying model(s)? How much data and state is a command class supposed to contain?

An example to illustrate my point: suppose you have a QStandardItemModel as base model, and a number of proxy models sitting on top of this. Each proxy model will do a transformation of sorts, such as filtering by occurrence of a certain value. Then if I create a command class to specifically alter one value in one of these proxy models, and the filter conditions change, the state of that command class becomes invalid. So I have to include the state of the filter as well, or a mapping to the ultimate, underlying model. Another option is to add commands for all of the state changes in the UI (the ones causing the filter condition to change, for example) as well, but the downside of this appears to be that the list of commands to undo becomes rather large.

What are the best practices here?

Answer 1

It depends somewhat on your application and how it is used, but here are the general guidelines I've used in the past for undo commands:

• Is it part of the data? If so, the user should be able to undo it.
• Is is saved somehow (remembered between application sessions)? If so, the user should probably be able to undo it.
• Is it related to the main purpose of the program? If so, undoable.
• Is it an often-done portion of the workflow? If so, likely undoable.
• Is it triggered based on something else changing? If so, it should undo when the other item changes back, not by itself.
• Does it reset every time *X* happens? You might be able to get away with it not being in the undo stack.
• Is it easily undone via the same motion (hiding/showing extra information, for example)? You probably don't want it in the undo stack.

Based on this and what you've written, I would probably tie the undo information to both the model (data) and the view, if the filtering is something that happens often and/or can't easily be changed back. If the filtering is simple (basic substring filtering like searching your email subject lines), then it probably doesn't need to be part of the undo state, and then undo commands would just be tied to the data.