Re: Generic undo stack for GTK+



On Wed, Jun 16, 2010 at 4:28 PM, Martin Nordholts <enselic gmail com> wrote:
> On 06/16/2010 10:01 PM, Holger Berndt wrote:
>>
>> Some time ago, there was some discussion about a generic undo stack in
>> GTK+ [1]. The talk back then didn't result in more concrete API
>> discussion. As undo/redo is part of the GTK+ Roadmap [2], I now shot
>> ahead and created an undo proposal page [3] for that. Comments are very
>> welcome.
>
> I think it would be unfortunate to limit the generic undo mechanism to a
> stack, when full preservation of undo-version controlled data requires a
> tree:
>
> 4   7
> |  /
> 3 5
> |/
> 2
> |
> 1
>
> In the above tree, 4 revisions are created, then two undos are made, and
> then two new revisions are created from revisions 2. You don't want to end
> up with the undo stack
>
>
> 7
> |
> 5
> |
> 2
> |
> 1
>
> and lose 3 and 4.
>
> Having a sane UI for this is a different matter, maybe most applications
> would only use the simpler stack based undo structure, but tree based undo
> apps should also be able to use the generic solution.
>

FWIW, this can be done in a stack assuming you've implemented ->duplicate()
methods on your transaction objects allowing you to duplicate transactions
and append them to the stack as the reverse transaction.

For instance, consider '+' = do and '-' = undo:

 4   7
 |  /
 3 5
 |/
 2
 |
 1

Would translate to: +1 --> +2 --> +3 --> +4 --> -4 --> -3 --> +5 --> +7

This is generally how undo/redo works in emacs, although I haven't
looked at that code myself.

The trick is when you get a new transaction and you are not at the
top of your stack already; i.e. when +5 initially happens: you need to
create and push the transactions -4 and -3 onto the end of the stack
before pushing the executed +5 transaction.

That being said, I am over all skeptical about this API addition inasmuch
as most applications need it in a different way, for instance some applications
can do undo/redo on multiple data sets with multiple open projects. Some
applications open documents have interdependent data making the maintenence
of separate undo stacks impossible.

I'm also worried what would happen if this would be added to GTK+ and that
entries and textviews started carrying some implicit history - generally you
want to keep GTK+ widgets away from the internal data model definition
of a said application; transactions should only run on the internal data model
and GTK+ should only reflect the model and driver the controller.

My 2 cents, Cheers,
     -Tristan


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]