Wish: Do we really need Expand/Collapse to be part of Undo History?

[ShynnSup]

I have no use for this, never had the need to undo an expand/collapse. If I need to change my layer tree I just do it again (manually collapse a previously expanded layer).

I would like to think most people work/think like this too.

From an objective point of view it is not good design, there is no explicit connection linking the two, and one might be content with how his layer tree currently is, while wanting to undo modelling actions.

If there is no consensus can we have a per-user option to exclude it from history?

I found a request from 7 years ago.

Undo/Redo history - Exclude layer state changes?

Is it possible to exclude layer state changes from the undo/redo history? If I want to undo the most recent change (or changes) to a model using ctrl-z, I have to cycle back through any more recent layer state changes. When I’ve undone the relevant change(s), I then have to manually reinstate those layer changes I wanted to keep! More worrying, if I undo a number of steps and then inadvertently make a layer change (even something as simple as visibility), all those potential redos are instant…

And another from 2 years ago.

Why are Layer Visibility changes part of the default "undoable" actions?

as the title suggest I find that for my workflow is pretty unconvinient to have changes made to the layers visibility included as default undoable commands, however I think that a layer must be automatically turned on IF a geometry change is made in that layer as result of “undo” otherwise the latest layer visibility should be preserved. for me having the layer visibility changing as I undo stuff simply makes my workflow harder, for me is equivalent of having camera changes as part of the defau…

[pascal (Pascal Golay)]

Yep, I hear you - it’s been on my list for along time. It is not a trivial task, I understand, but it is on the list and I linked your comments.

-Pascal

[Tom_P]

I’m suggesting a feature similar to the previous cplane, but for local layer panel adjustments. It’d act as a “previous layer state” command, not a conventional undo.

In particular, this feature would undo accidental alphabetical sorting by the “Name” column, which can be disruptive in projects with numerous layers.

(as I was using my bad english: “if you have a huge project with hundreds of layers this might foul you hard” I asked chat gpt to improve my post… see above)

[dale (Dale Fugier)]

@Tom_P

undo accidental alphabetical sorting by the “Name” column

This is already undo-able. Or did I miss something?

Thanks,

– Dale

[Tom_P]

@dale

Or did I miss something?

No - you missed nothing. thanks for having a look.
for me, everything regarding undo works fine.

I just wanted to point out:

• undo for the layerpanel is important for accidental alphabetical sorting. (and works at the moment)
• if we get an preference/option “exclude layer… from undo” i would love to see a separate command “_previousLayerState” similar to “_previousCplane”
• (just popping ideas…) or even a fine grained undo preference / command option ?
  • restore geometry yes / no
  • restore attributes / properties
  • restore blockedit yes / no
  • restore layer…

…
but I am a big fan of a general, all inclusive undo.

[eobet]

@Tom_P

for accidental alphabetical sorting

This might be out of the context of this thread, but I see there’s a “layer state” panel… you can’t save your custom sorting with that, to recall later or even have multiple custom orders saved to switch between?

[ShynnSup]

@eobet

This might be out of the context of this thread, but I see there’s a “layer state” panel… you can’t save your custom sorting with that, to recall later or even have multiple custom orders saved to switch between?

Layer State does not save sorting. Just tried. It should.

[brian (Brian Gillespie)]

@ShynnSup

Layer State does not save sorting. Just tried. It should.

Logged as RH-78967 LayerState doesn’t save sort order