undo?

[Russell Nelson]

Bernhard Reiter writes:
 > On Thu, Jan 20, 2005 at 08:03:24PM -0500, Jonathan Coles wrote:
 > 
 > > however, i'm not sure that the whole session file should be a sequence
 > > of commands. if it was, the only way to get the final state of the
 > > session would be to run through all the commands from the beginning when
 > > the session is loaded.

Once you have the list of commands that created a session file, then
*that* is the canonical representation of the current state of the
session.  A dump of the current state would simply be serving as a
cached copy of the state, and would not be authoritative.

Whether the state should be cached or not depends on how long the
commands take to execute.  If the commands run quickly, keeping a
cache to make the sesion load quickly would be a waste.  Only after
it's implemented could we make that decision.

Hmmmm.....  Why does it feel like I'm suggesting that Thuban be a
reimplementation of GRASS?  Maybe the GRASS folks got more things
right than it seems?  Maybe what GRASS needs is a modern front-end
which works like Thuban?  I hope that nobody thinks I'm criticizing
Thuban -- I don't mean to.  I'm just reflecting on the direction my
thoughts are taking me.

 > Yes, the a configurable number of last executed commands should be saved
 > to allow undo even after a save-load operation.

This is a good idea.

 > > also, it would further seperate the UI and Model components and allow
 > > much fuller tests.
 > 
 > Can you elaborate how it does this?

UI actions should produce a definite set of commands.  Calls into
Model components can be scripted using a command rather than having to
run the UI.

-- 
--My blog is at angry-economist.russnelson.com  | Freedom means allowing
Crynwr sells support for free software  | PGPok | people to do things the
521 Pleasant Valley Rd. | +1 315-323-1241 cell  | majority thinks are
Potsdam, NY 13676-3213  | +1 212-202-2318 VOIP  | stupid, e.g. take drugs.