[Bf-committers] Proposal to exclude tool settings from Global/Mesh Undo

[Campbell Barton]

On Sun, Nov 27, 2011 at 8:22 PM, Dima Glibitsky <dima.glib at gmail.com> wrote:
> In most of the cases, changes to ToolSettings push undo stack, which
> has the following impact on workflow:
>
> 1) To undo/redo meaningful changes to scene contents, user often has
> to go through a number of steps that don't change anything in scene
> ("meaningless" steps from the user's point of view). In such cases,
> the side-effect of changing tool settings on the way is usually
> undesirable and even hindering.
> 2) Another bad side-effect is that any change to tool settings makes
> it impossible to redo currently undone actions.
>
> In short, users are focused on content manipulation, so
> non-content-related history pushes usually just get in the way and
> unnecessarily pollute undo history.
>
> I suggest that in this concern Blender should behave similarly to
> other applications (e.g. GIMP), where each undo history step is
> related to the actual modification of content.
>
> 3) On the other hand, sometimes it is convenient to have a history of
> some (e.g. brush) settings. To be more specific, these are colors and
> slider-regulated properties, such as Weight, Radius, Strength, Jitter,
> and so on (because it takes more effort to set them precisely).
> However, even in this case they should have a separate history -- of
> the "recently used" type, like Colors history in MyPaint.
>
> Actually, there are already precedents of non-undoable/redoable tool
> settings. Besides the 3D cursor (though it's not in ToolSettings, it's
> still separate for each scene), they include:
> - ToolSettings.use_grease_pencil_settings
> - ToolSettings.edge_path_mode
> - ToolSettings.edge_path_live_unwrap
> - ToolSettings.normal_size
> Even though they push undo stack, they do not change on undo/redo.
> Maybe there are others as well, I didn't check each of them.
>
>
> So, summing up, the proposal is the following:
> - Changes to ToolSettings shouldn't be recorded in Global/Mesh Undo
> history, and shouldn't change on Undo/Redo. This may be as well
> generalized to other settings that don't modify the content (e.g.
> display settings, like Mesh.show_all_edges or
> Mesh.show_extra_face_area).
> - Introduce "recently used" option for Color & slider-regulated
> properties. For example, there could be a submenu with recent values
> available when right-clicking on the slider/color.
>
>
> P.S.
> I have also noticed that some Mesh parameters don't change on Undo/Redo too:
> - Mesh.use_mirror_x
> - Mesh.use_mirror_topology
> - Settings in Mesh Display panel
> However, use_mirror_x and use_mirror_topology are undoable/redoable in
> Weight Paint mode (perhaps there is a bug?). As for Mesh Display
> settings, I think it would be logical to make them not push undo stack
> ;-)

I'm not especially against this change but we didnt have complaints
about it before so Im not sure if its really that big of an issue?
(undo was happening on changing draw type too and nobody complained so
maybe users are just not fussy about this stuff).

There are 2 ways we could do this,
1) have changes to tool settings not cause undo pushes,
   this is by far the easiest thing to do, however it only saves on
undo pushes - other tools that undo will still restore the old tool
settings.

2) 'Do it properly' - which would be to manage this like we do for
images and screen data, where the tool settings are managed outside
undo memory. The main drawback here is we would need to move tool
settings into their own allocated pointer and then copy the old
settings into it on file load, annoyance is now there is a 2.60 tool
settings and 2.61 tool settings and we need to remember not to use one
since its old info.
Not totally hard but IMHO the trouble to do this outweighs the benefits.

3) we might be able to do #2 but without moving tool settings into a
new pointer, using a similar method of copying back data after undo,
would still involve storing it somewhere but think if we could manage
that it would be more acceptable and be less annoying.
So if someone comes up with a patch to do this, +1 from me.

-- 
- Campbell