Take layer state into account in the undo history

Hey there,

Did you notice that making a layer visible or not isn’t taken into account in the undo history?
You can not open a file, disable a rough layer, or enable a missing layer and save. You need to make a “dummy” operation for a * to appear next to the file name.

Also sometimes when undoing, if layers are not set back in place as they were, you can have a hard time with your history.

What about giving the ability to take layer visibility into account in undos?

5 Likes

Just a historical note: undo for visibility has been disabled explicitly because it cluttered undo history, it was an explicit request from painters about 6 or 7 years ago.

Now when I think about that, I guess we could just compress all visibility changes into one undo step. Perhaps, even when visibility is changed for different layers.

2 Likes

Maybe do a pool to make it easier for users to vote? :wink:

  • Stay as it is
  • Include layer properties in undo history

0 voters

1 Like

I would compress them as one only if they were toggled together, locked together etc in one command.
Otherwise having a way to undo with layer state into account aside the current undo could be a solution ?

Even a checkbox in the settings to take it into account or not would be enough to me (as long as layer state operation are not slugged together)

I’m a bit torn between having this and not. I can remember many times where this would have helped me but also a lot of times where this would have simply annoyed me. It’s like I want a seperate undo stack just for some layer states.

1 Like

I would prefer it only like an option.

Additionally I like to have a notion of save document operation, like photoshop does.

And I am really starve for a name of the brush which made a stroke in history panel.

1 Like

While I can see your point I think not having visibility in undo is a plus. I feel like the clutter in the undo history would be much more annoying than having to do a dummy operation to save. Also I really like how I can open a file change de visibility in some layers and then close it without the program asking me if I want to save any changes.Somehow I think that what Takiro said of having a separate undo stack for layer states could be a good option, however don’t know how feasible that would be in code or how functional it would be.

Because it cluttered the undo history? * Confusion* I guess it can appear a bit annoying if you look it a certain way… It should register the change somehow though. Not being there seems much more problematic than being there.

Having two undo stack would really be annoying and would confuse the new comers. And then there would be countless youtube videos and reddit posts blaming the devs for having two docker which do similar things. :slight_smile: . You know posts like “i would switch from photoshop if only krita didn’t have two undo dockers” :stuck_out_tongue:

Having said that I agree with @dkazakov and @MangaTengu to compress the undo states into one if done in succession and keep the single toggle separate. That way it would not clutter the undo docker.
We currently have an option for de-cluttering and compressing repeated stroke actions.

Screenshot_20200821_100553

We can have a toggle in this dialog to toggle layer actions in the undo history.

Well there are already 2 history stacks in krita, the brush preset history and the undo history docker. While the brush preset history docker is not a undo stack both are history stacks.
Having the layer states in the undo stack just seems like a waste, I only noticed recently that the states were not saved by themselves or not put in the undo stack and I actually never missed it.

About it confusing newcomers i don’t see how it could, have the undo stack as normal, they already cant undo layer states so the usual expected behavior is already set. I believe changing the behavior of something that already exists will cause much more confusion that adding something new that adds new functionality.

While I understand having 2 stacks is not very practical, to me feels better to separate both things. If the userbase asked for its removal before i believe there was a reason. I fear that just adding back will just make we go in circles in asking for a functionality and asking for it to be removed, maybe studying how people would use it and how is the usual workflow to be able to implement it in a way that is good for most cases. I think that would be better for the users than just adding it back with the cumulative undos.

Another suggestion that could be relevant is what MangaTengu said about having in the settings a way to toggle if the layer states are taken into account for the undo stack or not like a “feature preview”, if possible. For a first moment I think just giving the users options is more safe, see how they will react to the new feature and then if the acceptance is high ask if they want that to just be the normal behavior or not.

One kind of fix would be to just change document modified flag,
without appending action to undo queue. (document would be marked with [*], and ask user about saving)

/AkiR

1 Like

They both are very very different. one is a history of preset used and other is a history of actions by user. By that logic you would also club together color history :slight_smile:

Yes that I why I stated that it should be a setting (a toggle) in the undo history docker setting dialog, we already have a dialog for cumulative undo. we can add this toggle there.

I’m not proposing a different stack.
I’m proposing to allow navigating through the same history in different ways like up and down are more granular than page up and page down for example:

  1. stroke
  2. stroke
  3. stroke
  4. layer visibility
  5. stroke

classic undo (let’s say ctrl+Z) would go back from 5 to 3 in one step
finer undo (let’s say alt+Z) would go back from 5 to 4 and then from 4 to three in a second step

I’ll comment on all the replies in one message:

  1. Having two completely separate undo stacks is not possible from the technical point of view. Because one stack may link to layers removed in another stack.

  2. Having some weird compression of your choice for the visibility commands is technically possible

  3. “And I am really starve for a name of the brush which made a stroke in history panel” that is doable and sounds as a good idea.

I think to try to do such a package:

  1. All visibility change commands will be compressed into a single history item, even if they change visibility of different layers.
  2. Other properties, like lock and blending mode will be compressed on per-layer basis.
  3. All layer property operations will mark the image modified (when adding an undo history item, the image is marked automatically).
  4. There is a technical trouble: if you set a layer invisible, then visible again, there will still be a single undo history item for it, which would do nothing. It is a technical limitation of our undo system. I don’t know if it is fixable.
1 Like

Is compressing worth it ? I doubt the history will be flooded with visibility toggles as long as toggling a group of layers is represented as 1 history item and not 1 per distinct layer

Some artists turn on and off a layer several times to check how it affects the composition… then yes, the undo history will be flooded with show/hide layer commands.

And if you were doing that on-off to check if a particular change you made works within a composition… and it turns out not to… you can gather that first doing through all those undoes can get quite annoying.

dmitry: Maybe we should let the compressor remove two subsequent actions if it turns out those are just flipflopping a property??? (though not sure if this gels…)

1 Like

You’re right i got it now

I’d be okay with marking the document as changed, seems logical (also for some other display options I’d like to have changed with the document, btw.)

But creating an actual undo step seems too dangerous to me.

Creating a new undo item drops all items you can redo right now. Changing visibility has been safe for a long time, if people suddenly must remember to not touch visibility when checking if they did something they may not want to keep, that may result in quite a few upset users…

Besides, I also often have a layer with lines basically when guides and painting assistants are not flexible enough, or even if I don’t want to use the reference image feature because a (file-) layer can be adjusted in many more ways.
In such cases I prefer if visibility is merely considered a display option and does not change as I undo to check something.

I understand your point indeed.
But there is also disadvantages to ignore layer visibility:
You can undo things done on a layer made invisible without even knowing.

1 Like

Just btw, do you know the impacts of having a bigger undo stack ? I always add a 0 to a vanilla krita so I have a 300 steps stack…