True, I wonder how hard it would be to add an option that ensures undo makes layers that change visible again…
1 Like
Yes, I confirm, on my side I often show/hide layers while I’m working and sometimes, I undo things and didn’t see that I’ve made undo on layers that are not visible anymore…
Grum999
2 Likes
Hi, all!
Could you please test this package?
https://yadi.sk/d/VQAgaegBlOdVnA
Or build from source:
https://invent.kde.org/graphics/krita/-/merge_requests/479
What it does:
- Compresses all the layer properties changes into a single command in per-layer + per-property manner (already present in nightly builds)
- For several properties it compresses changed in per-property-only manner, that is, there will be only one command when changing multiple layers:
- visible
- locked
- onion skins
- alpha locked
- selection active
Does this compression look good for your workflow? Or the way without undo was better?
1 Like
Bumping this topic to get more eyes from painters.
1 Like
Hi, All!
I have also built an AppImage for testing:
https://yadi.sk/d/WNz7lBjliPhXXg
I need your feedback! 
Thank you for this appimage. I tested the opacity, blend mode and locking etc. I think this works as expected and I didn’t find any issue with workflow. I would like to know opinion from other participants in this thread
Hi, all!
I am still looking for painter’s feedback about this feature. We had heated disputes about it multiple times, we should finally resolve that
I have prepared the updated packages for Linux and Windows:
- Linux x64: https://yadi.sk/d/FbI4sahwm7yxIg
- Windows x64: https://yadi.sk/d/YcmvXrNmt6oxBw
2 Likes
I don’t have a strong opinion about this new functionality either way.
A quick test shows that it works in terms of various layer properties and prompting for saving (or not, as appropriate) if you try to Close.
One minor thing I saw is that if you perform operations and use Edit -> Undo, then after all operations have been undone, the Edit -> Undo shows the word ‘Undo’ as not greyed out, unlike 4.4.1 which shows it as greyed out in this situation.
Also, for a freshly opened file, which can’t have an Undo performed, the Edit -> Undo is not greyed out, but this is the case in 4.4.1 as well.
Also, for a freshly opened file, which can’t have an Undo performed, the Edit → Undo is not greyed out, but this is the case in 4.4.1 as well.
That sounds like a bug. You seem to have a brilliant eye for bugs! I’ll check that 
I can’t help it, but merging multiple actions across layers seems awkward to me, being able to undo multiple action might safe some clicks/key presses at times, but being forced to do so is also a limitation.
And having visibility as undo step requires changing my habits some, since it throws away the redo steps now.
I have to admit I’m rather indecisive, i.e. often go back and forth a couple of times when I’m not quite convinced my last few strokes made it better or not. And if I can’t toggle layers anymore I had hidden for editing purpose, that’s a limitation to me that makes the decision harder.
I guess I could adapt to those changes somehow, but right now I just don’t see why I’d want it.
It seems visibility takes onto account only with eyebutton clicking, using shortcut ignores history toggle – and I am ok if it not going to be changed.
You’re right, toggling by shortcut doesn’t create an undo entry. I wonder if that’s intended…
(To be honest, I never checked if you can set a hotkey for that action, in any case there is no default one and I don’t really want to do it by keyboard either)
Hmm, I think the option to turn off/on this feature should satisfy anyone.
In case it is problematic in developing side, we need a pinned poll with the question, so every forum users could notice and vote. Now it is 50/50 of just 20 users.
The problem is, of course, that making everything an option is a bad idea: an option like this doubles the code paths that need to be tested and having too many options makes it hard for users to find the options they need.
And as for putting this to a poll: that’s a bad idea as well. Workflow design isn’t something that’s done by comittee or democratically.
2 Likes
I don’t argue about coding/programming work.
But
I am sorry, you are talking about Krita? Compare it:
History dock options:
With:
it even doesn’t fit the fullhd screen…
And with:
Plus some more engines…
Ok. But in the particular case isn’t workflow design already done?
1 Like
I’ve missed this topic and appimage provided in august/september, sorry.
As I’m waiting for this since a while, I’ve started to test the bedc5f2 appimage
On my side it’s ok:
- Hide/Show layers are taken in account in undo/redo stack, compression doesn’t hurts me
- Hiding/Showing a layer now update the file to unsaved state and that is a very good thing
- Lock/unlock works properly too
The only thing I found is a little bit tricky to manage and I don’t really consider it as a bug, but it could be disturbing when it occurs…
Hide layers 1, 2
And after show layers 1, 2
(or hide 1, 2 and then show 2, 1, or simpler: hide layer 1, show layer 1)
Finally there’s no change, all layers are visible.
But there’s an undo action in stack without any visible action of what have been undoed (do undo, nothing change…)
That’s not a big problem.
But it’s a little bit disturbing to see that something can be undoed without seeing what have been undoed…
I have absolutely no idea about how this can be solved (not even technically, but from a user point of view… doing action that will automatically cleanup the undo stack seems a little bit weird)
Grum999
That sounds as a reasonable blocker
That is a “bug” and if we greenlight this change it will have to be fixed
I’m personally agree with Boud, too many options make life of both users and developers more difficult.
Yes, that is a limitation of the current Qt system. Theoretically, we could extend it and fix this issue, but I’m not sure it is worth it.
To all:
I have a feeling that we should drop this idea of undoable visibility change and just fix the bug of not resetting the modified state. The main concern for me is the @Lynx3d’s one: changing visibility now clears the redo stack. I’m not sure that is a good change…
What do you think about the cleared redo concern?
1 Like
Not sure to understand but for me, in my workflow:
- I made some strokes
- I hide a layer
- I continue to work on another layer
- I made undos
And then, if there’s no undo on layer visibility, I can’t see that what I’ve made on this hidden layer is currently undoed (this ocured so many times 
) and I’m finally completely lost: what has been undoed, since when… 
After I don’t know, maybe my workflow is not good, I’m often working with 50~100 layers and always change their visibility…
And worse: currently if you lock a layer, the undo is applied on a locked layer
- Made some strokes
- Lock layer
- Undo => locked layer is modified by undo but stay locked
- Redo => locked layer is modified by undo but stay locked
And as the unlock status is not modified by undo, that’s really hard to understand what’s happening.
On locked layer, no change normally should occurs…
From a developer point of view, I agree, too many options and the code is difficult to maintain.
But for a user point of view, on my side I prefer to use software that let me to choose how to work
In my workflow, that’s a normal thing as hide/showing a layer is a part of my process.
It’s like, do strokes(A), undo(A), do other strokes(B): you can’t redo strokes (A) after strokes(B)
Grum999
I’ll just say that even as a developer, I prefer giving options over forcing design decisions down a user’s throat. It might mean more debugging for me, but if it means more users are able to enjoy their experience, it’s worth it. And as a user, I vastly prefer having options over not having them. If an option list gets long, it just needs to be split into categories to make it usable again.
I think this needs to be fixed. Locked state should be part of the undo stack as well.
I don’t think I’ve weighed in on this overall topic yet, but my opinion is that layer state should be taken into account in the undo history (I’ve run into issues with my work occasionally because of this), but if that doesn’t work for some people, it absolutely should be an option so those of us it helps can have it and those who it hurts can turn it off.
1 Like