Currently, the provided appimage fixes this problem 
But, as for the visibility, this clear the redo stack…
Like the inherit alpha or alpha locked options does.
Grum999
Hello all!
I tested the alpha build to see if this changed would fix an issue noted with Compositions.
The issue is that adding new compositions doesn’t flag the document as “changed” so the new composition(s) can’t be saved to the file until a different change is made.
I figured that this alpha build would help since the compositions effectively act as layer visibility masks but that doesn’t seem to be the case.
Anyway, thanks for putting this test build together @dkazakov!
Apologies if my reply is considered off-topic.
Just report it on bugs.kde.org
Hi, all!
I have just pushed a patch that fixes the problem in another way. It makes visibility change mark the image as “modified”. And this modified state will not go away until the document is explicitly saved.
Could you test these packages and tell what you think about that?
Tested. Now it is like in photoshop – “unsaved” status after changing visibility.
Personally I am ok with it because it doesn’t touch a workflow. So, additionally it will be good to know when in a past I saved a document.
Thats why I have a question. Is it possible to add a info-mark in a history when document was saved? Something like “brush stroke (saved)” or maybe different fill color of action?
Hi, all!
After a bit of discussion on IRC with @Deevad and @raghukamath and @halla, we came up to the following decision:
In Krita 4.3:
- changing visibility is still not undoable
- changing visibility of the layer will mark the document as dirty. This dirty sign can only be lifted by saving the document once again.
In Krita 5.0 there will be a behavior change:
- changing visibility will become undoable
- when changing the same property of the same layer multiple times, undo steps are compressed
- when two consequent layer visibility changed compensate each other, e.g. when visibility is toggled to and fro, then the two undo steps annihilated and they both are removed from the undo stack
That is, in Krita 5.0 changing visibility will behave like requested in the beginning if the thread.
There was a dispute about keeping the old behavior as an option, but we decided not to do that, because it can potentially cause bugs with marking the document as dirty, which is potentially a dataloss. So there is no config option for that.
The change is already merged into master. You can also test proof-of-concept AppImage from this MR: https://invent.kde.org/graphics/krita/-/merge_requests/646
5 Likes
4.4.3?
Grum999
yes, in 4.4.3
This is a nice feature to have. Can you make a separate thread. I imagine the mark can be a green dot or something.
To clarify the confusion, “krita/4.3” is currently our substitute for master as a next-release branch.
So if you build the 4.3 branch you actually get “4.4.3 alpha” 
But the next major release is supposed to be 5.0 from master…like, for real 
2 Likes
Grum999
This change feels wrong to me 
3 Likes
Yes, I also find it a bit annoying, more than anything because it affects my workflow, sometimes I make changes to my sketches and hide layers to have better visibility, then when undoing to better review the changes, the layer that I hide is activated and it affects me, I hope they revert this option 
6 Likes
It feels absolute strange to me. Is it possible to make it an chooseable option instead?
Michelist
2 Likes
When this topic was initially opened it was stated that around 2013 visibility was remove from undo history, per artists request. Then this topic was made asking for it back.
The third post was a pool, that I believe, has received 20-ish votes until the implementation of this feature. Even so it painted a picture that half the people didn’t wanted (and the other half wanted) this visibility onto the undo history.
If your user base is practically split in half, and you have the option to make this behavior a toggle option in the General Settings, how could you not do it?
All this to me to say: Make this option an Option. Please. It is annoying for my workflow.
Cheers
3 Likes
I can understand that for other it could be annoying, but from my point of view and according to my workflow, a rollback on this will be a bad regression 
Having an option seems to be a solution to let all users being satisfied, but it currently seems not to be something on which @halla agree:
But clearly there are users who want it and some who don’t want it… 
Grum999
There is a tracker report regarding the behavior change here: 446889 – Layer visibility changes should not be included in the undo stack (or behavior should be optional)
3 Likes
The problem is that layer visibility on one hand clearly is document state that gets saved, but at the same time it is often necessary to temporarily change visibility, especially if made a mistake like painting on the wrong layer yet again…
As mentioned in the bug report linked above, my idea would be to simply have two visibility states, a “document” state, and a “view” state.
Krita even already has some attempt for temporary visibility toggles with the undocumented and unnamed shift-click feature that turns the visibility icon blue (and hides all other layers), but IMO it’s implemented the wrong way and basically messes with the document state anyway, it just tries to remember the “normal” state but gets easily confused and thus fails to restore the original document state. And with 5.0 it’s pretty much broken entirely since all the toggles it does become undo steps too…
For everyone it is different, I would not say it is bad, but certainly we are divided in half, I think there may be a solution, we just have to wait.
After some digging I finally found the discussion that caused this big change/delay for my workflow, so I’ll give it my 2ct here.
I see in this topic that the option that was re-added and I’d like to voice my opinion: layer states in the undo history work very counterproductively. I switch layers on and off continuously and am now wearing down the undo buttons to simply get to a mismanaged stroke.
Is there any code I can adjust manually to remove layers from this behaviour in Krita? At this point I’m frustrated enough to risk any instability.
Other than that Krita is my go-to program for years.
3 Likes