Re: Undo framework

["Iain *" <iaingnome gmail com>]

> Do you allow nested undo groups? This is rather important
> if you want to compose actions from smaller actions and still allow
> scripts or other higher levels to combine these into a single undo step.
> We make heavy use of nested undo groups in GIMP.

We allow one level of nesting, I can see your point about allowing
deeper nesting though and will think about how it could be done. I
suppose this is as much of the "merging" of actions that should take
place, I don't see that the UndoManager itself should support
automatic merging as each application has different requirements for
when a merge should happen, but if we allow multiple nesting of
actions then the applications can merge as they see fit.

I can see the reason for the non-UI parts to go in GLib, but is there
any precedence in having stuff like this in GLib? If it was to go in
GLib it would be its own seperate library, which for one thing would
kinda suck?

As for transactional stuff, I would think that it seems overkill for
most applications, although it'd be great if we could work out some
way to allow those that want it to be able to implement it on top of
the base system. I can't see how you could make it generic enough to
make everyone happy.

> Undo/Redo methods aren't sufficient.  We've found it necessary to
> differentiate Redo and Repeat sometimes.

I'm not sure how repeat fits in here exactly, although maybe I'm not
thinking of the same thing as you are. I'm thinking of GIMP's repeat
filter functionality, and while its similar conceptually, I'm not sure
why it is something that the undo manager should be taking care of?

iain