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, [email protected] "Protect your digital freedom and privacy, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm"; -- Mailing list: https://launchpad.net/~geda-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~geda-developers More help : https://help.launchpad.net/ListHelp
