geda-developers team mailing list archive

[Ivan Stankovic <pokemon@xxxxxxxxxxxxxx>]

On Wed, Dec 19, 2012 at 05:30:45PM +0000, Peter C.J. Clifton wrote:
> Regarding file-formats, consider also:
> 
> Database vs. file? (Would a database even require explicit saving?)
> ZIP container vs. separate files

I'd make archives and databases optional. Support for them can always
be added later and working with plain files makes debugging so much
easier.

> Undo is an interesting, and partly related question too. Should it
> be supported by the core library, or a feature of the editor(s)? (We
> might want to turn it off for automated input).

The undo support should probably be in the core library to make it
easy for tool developers. But I would also decouple it from the
data structures and make it optional.

> Should undo be inherent to manipulation of the data-set, or
> explcitly requested? (If the former, some logical grouping hints
> might be required to bundle change-sets together).

I think it should be explicitly requested, because we really don't
want to make low-level data model operations so complex as to require
an undo description. Undo actions should ideally be composed of
a number of smaller, simpler operations on the data model. Besides,
different tools may want to group the same set of operations differently.

> Can we use GObject properties to implement undo? We might need an
> object's entire internal state to be completely defined by its
> properties so this can work? (That is probably a good thing anyway).

Sounds nice, although I fear it might end up trickier than it seems at first.
The biggest problem I see is that you don't really want to expose the entire
internal state, since then everyone can change it at will. I'd prefer that
only the undo system has access to the internal state.

Here's an idea. When a data model object modifies its state, it also
fills a structure with the information about the change and then emits
a specific signal and provides the structure to signal handlers.

The undo system then just listens to all the objects that might be involved
in an undo action and merely records the structures as the signals come.
The undo system need not know the specifics of these structures, they
may be totally opaque; but we would need a different object that knows
how to use the information within those (type-specific) structures to
recreate the previous state.

In this way no internal state is leaked. However, there is the cost of
preparing the structures and emitting the events. (Maybe that can be
optimized somehow...)

-- 
Ivan Stankovic, pokemon@xxxxxxxxxxxxxx

"Protect your digital freedom and privacy, eliminate DRM, 
learn more at http://www.defectivebydesign.org/what_is_drm";