[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: Generic undo stack for GTK+
From:       Tristan Van Berkom <tvb () gnome ! org>
Date:       2010-06-21 20:29:37
Message-ID: AANLkTilEYJQWtJ0qF4s20uhMfrsZyAvPDcOQUmRd5eWl () mail ! gmail ! com
[Download RAW message or body]

On Mon, Jun 21, 2010 at 4:03 PM, Holger Berndt <berndth@gmx.de> wrote:
[...]
>
> [...]
>
>>You don't want your business logic driven by your onscreen widgets
>>haphazardly this way - you need your undo/redo stack to interface with
>>your internal data model - and you want your views to be synchronized
>>to the model.
>
> Yes. In the case of TextView/TextBuffer, the undo stack would be
> associated with the GtkTextBuffer, and the GtkTextViews would be
> synchronized to the model. I don't see the problem here.
>

What happens when you have multiple buffers editing separate
but interdependent project data ? Is the new code introduced
to be so complex that it will handle the interleaving of commands
on separate datasets into a single stack ?

Is the developer then forced to create a convoluted design where
he is forced to use manipulate GtkTextBuffers and maintain
their life-cycle over the user's session in order to leverage the undo/redo ?

What if the project involves an invariable amount of text segments
(like Glade text properties or layers / text objects in a scene editor
or image manipulation program);

How does this approach help you design an overall clean
separation between your model, display and command code ?

 a.) why should undo/redo be buffer centric instead of document centric or
      session centric ?
 b.) what kind of assumptions can GTK+ make about what data types the
      document is composed of or how the application's data model is defined ?
      none really.

Cheers,
         -Tristan

>>Although the time it takes to define such interfaces and undo
>>mechanics is negligible in comparison to the time needed to properly
>>analyze the particular requirements for an application like the Gimp or
>>Glade for instance. Not to mention the time debugging all the intricate
>>client code that manages interdependent transactions on the abstract
>>client data model - all this client code that defines each transaction
>>still needs to be written, and that's generally a challenging task.
>
> This paragraph is very true, but not only for undo stacks, but
> basically for all container types.
>
> Holger
>
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]