Re: RFC: new features

[Tristan Van Berkom <tvb gnome org>]

On Thu, Jan 12, 2012 at 9:37 PM, Paul Davis <paul linuxaudiosystems com> wrote:
> On Thu, Jan 12, 2012 at 7:31 AM, Ross Burton <ross burtonini com> wrote:
>
>> Tasks has a undo manager/undoable implementation and that's
>> implemented by function pointers that do the right thing, so you can
>> probably implement both methods with that.
>
> well, sure. i guess i was assuming that much. maybe i'm just thinking
> too much about how you actually implement undo/redo, not what the API
> for "undo the last change" or "redo the last undone thing" looks like.

Actually, my latest attempt at undo/redo, after analyzing the
difficulties which cropped up in Glade I've recently taken a
wildly different approach.

Hint, validation of whether a newly created command is a key
point in a data-model centric undo/redo system, there is much
pain involved when trying to mount an api "layer" on top of
an undo/redo system which interacts with the data model.

In this light I've decided to make my data models themselves
implement an "executable" interface, depending on object state
and of course, object type in a complex hierarchical model,
an executable object can simply refuse to create a command which
operates on the model.

I've found this greatly reduces complexity in policing command
validity (for instance if I were to apply this to Glade,
then a derived widget adaptor for say, a GtkBin widget could
simply refuse to create a command which adds a second child
to the widget... in the process it could even pop-up a dialog
informing the user why his request was impossible... Glade
is a good example here because there can be many specific
cases where a command would fail... centralizing that check
work on the widget adaptors make's a lot of sense).

Possibly it makes sense for GtkTextView to implement it's own
undo/redo system internally, if it can be assumed that the
text view (or text buffer more likely) is really only modifying
text.

However it would be good to be able to disable that feature,
consider for instance an elaborate implementation of GtkSourceView:
perhaps in that case there are many portions of text, but also
perhaps the underlying buffer implementation should be implemented
with "symbol" objects, possibly making reference to objects
constructed/introspected from a loaded gir file... in that case
implementing undo/redo on a "code structure" data model that
is displayed in a derived GtkTextView should be done separately
from the base "only text" implementation.

Anyway, some food for thought...

Cheers,
         -Tristan