Excerpts from Gary Martin's message of Wed Sep 15 15:15:20 +0200 2010: > > In absence of version support, please always make "destroy old version" > > and "destroy current version" separate UI actions. > > No activity allows a user to "destroy old version", that's a task the user > would need to use the Journal erase item for. The "destroy current version", > or a more friendly description would be "save my changes to the instance I > resumed" is the standard behaviour of other Sugar activities.
You just seem to be using different terms. To be clear about it, these are the terms I used and their meaning: old version: the one that got loaded when the activity started current version: the one that the user has modified, but not saved yet Sugar automatically saves entries when switching activities or closing them. Each time it saves an entry, the old version is destroyed and only the current version gets retained. If the machine crashes before an entry is automatically saved, the old version is retained and the current version destroyed. There are only two ways to retain both versions: Keep and version support. > Are you suggesting that, in the _current_ Sugar, every time an activity is > resumed the activity should keep a new duplicate Journal entry? Or perhaps it > should never auto save the users work on Stop? Most Sugar activities don't provide a way to destroy the current version. If they did, they should make it a separate action (e.g. "Revert"), not tied in any way to the Stop action. That's all I'm saying. Sugar itself should provide version support in the near future, even if just trimmed down like only keeping up to three versions. But as you said that's a different topic. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/
signature.asc
Description: PGP signature
_______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
