Feature Requests for Undo History

Bug #251205 reported by Brynn
2
Affects Status Importance Assigned to Milestone
Inkscape
Invalid
Wishlist
Unassigned

Bug Description

Hello,
1st I should say that I don't keep up with bugs or other development issues, or subscribe to the mailing list. So these things may have already been discussed. But I've searched here at LP and don't find anything relevant.

2nd -- I LOVE the Undo History!
When using it, I notice how like items are grouped. This CAN be very helpful, but the way it's done can also be very confusing. For example, I have 2 objects -- both have a solid fill, one has 2 gradients overlain, and the other has 1 gradient. If I work on gradient 1 of object 1, change a stop color, add a stop and move a stop (change offset); then I work on gradient 2 of object 1, move the handles and tweak the stop colors; then I go to object 2, gradient 3, move the handles, add a stop and move the stop (offset) -- all those changes are grouped together. So if I want to Undo a particular change I made to one of the gradients, there's no way to know which one of the items in the group is the one I want to Undo. All I can do is undo one item at a time until I've lost the step I want undone -- which of course represents no change from previous versions.

Another example: I have 3 objects, 2 rect and 1 ellipse. The creation of the 2 rect are grouped together, yet the ellipse gets its own entry in the Undo History. Then I go and set the Fill colors. But the filling of all 3 objects are grouped together. In this latter example, it may not seem like a big deal. But in the 1st example with gradients, depending on how one edits the gradients, an "Undo group" can contain hundreds of items!

I think it would be helpful if the grouping of like items in the Undo History was further subdivided by object....or by object first and then by task. Or taking the idea a step further, I think the grouping of items in the Undo History could be eliminated entirely, by identifying the target of each action. So in my 1st example with the gradients, a single item might be "Move handle of Gradient #a" or "Add stop to Gradient #b" etc. In my 2nd example, the resulting items in the Undo History might be "Set fill color for Object #c" or "Change opacity for Object #d" etc.

I don't know a whole lot about the XML Editor, but I notice that everything seems to have ID numbers. So it doesn't seem like much of a stretch, to use those ID numbers to identify items in the Undo History.

I 1st broached this subject in a topic discussed on the InkscapeForum.com forums (http://www.inkscapeforum.com/viewtopic.php?f=28&t=1285). In that thread, a couple of other ideas were touched on:
Clearing the Undo History (like in The GIMP). One comment about this is that Inkscape doesn't gobble up memory like GIMP, so there's no benefit to clearing the Historry. Although it is mentioned that there may be other reasons for clearing it; eg - as I've pointed out, editing even moderately complex gradients can create hundreds of items in the Undo History, and currently the only way to manage the items, is to save your work, close the program and reopen it.

Also mentioned in the InkscapeForum topic, is undoing a single item without having to undo everything back to that point. I'm not sure if that would be possible, but someone else suggested it might not be hard to do, and named an program in which it was possible.

So I guess that's it. I hope it's not bad manners to group all these suggestion into one "bug". But they are related, in any case.

Thanks for listening :-)
Brynn

Tags: undo
nightrow (jb-benoit)
Changed in inkscape:
importance: Undecided → Wishlist
tags: added: undo
jazzynico (jazzynico)
Changed in inkscape:
status: New → Confirmed
Revision history for this message
Brynn (brynn4inks-deactivatedaccount) wrote :

On reflection, 11 years later, I don't think this request is worth migrating to GL.

Closing by marking invalid.

Changed in inkscape:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.