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?
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.
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.
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. . You know posts like “i would switch from photoshop if only krita didn’t have two undo dockers”
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.
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)
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
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:
stroke
stroke
stroke
layer visibility
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
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.
Having some weird compression of your choice for the visibility commands is technically possible
“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:
All visibility change commands will be compressed into a single history item, even if they change visibility of different layers.
Other properties, like lock and blending mode will be compressed on per-layer basis.
All layer property operations will mark the image modified (when adding an undo history item, the image is marked automatically).
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.
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…)
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.