On Mon, 2003-12-08 at 13:13, Alan Horkan wrote:

Are there any plans to work on Infinite Undo? Some sort of journalling or suchlike? Should I file an RFE?

Primarily from a usability point of view I dont like ever needing to (have a preference or even) answer the question of how many levels of undo I want. Users of course want as many levels of Undo as they can get.

There would probably have to be some upper bound. I can see after some long, heavy editing session, the memory footprint getting quite large. If the undo level isn't up to the user, how would the application limit the amount of memory it uses (not a rhetorical question)? I imagine at some point, old actions would have to fall off the end of the list.

I get that memory management can be very complicated in a raster graphics programs with all sorts of effects but I dont quite understand what the problem is in a vector graphics application.

You still need memory, but not at the same magnitude. A vector app could probably support a much higher undo level than a raster image program, since Inkscape is only manipulating SVG nodes and their properties.

Mike

On Mon, 2003-12-08 at 13:13, Alan Horkan wrote:

Are there any plans to work on Infinite Undo? Some sort of journalling or suchlike? Should I file an RFE?

Well, in principle there's no reason we couldn't make Undo unlimited, short of actual memory constraints. I certainly don't mind having upped the limit.

The transactions model I added to the SPRepr layer does essentially record a journal of changes during each transaction (a linked list of SPReprActions). It holds references to the actual SPRepr nodes affected, rather than copies, so it is pretty memory-efficient.

You can still have some worst-case scenarios though -- e.g. if many large subtrees have been deleted over the course of the editing session. They'll all unavoidably take up memory in the undo list, somewhat contrary to user expectations.

So, really the choices are:

A. have a (perhaps user-configurable) predetermined undo cutoff (either in undo levels or bytes)

B. allow the user to manually prune the undo list

C. crash when a large undo list OOMs us

(Note that these options are not mutually exclusive...)

Undo accounting in bytes is tricky as many log entries will share data, but certainly doable.

Realistically, are users ever going to backtrack through more than ~300 levels of undo anyway?

Assuming we could actually perform undos that quickly (unlikely on a very complex document...) 300 levels of undo means a full minute of clicking at a sustained rate of 5 clicks/second. Ouch.

Having an undo history window would mitigate that somewhat, but that many undo entries would still be pretty unwieldy. Assuming a decent-sized thumbnail (ignoring the memory cost of that + descriptive labels), 300 entries means scrolling through almost 19 screen-heights on a display 1024 pixels high.

-mental