Sorry but i completely disagree, dockers being in settings makes zero sense. they are not settings they are internal windows in a sense, makes total sense for people to not look for them in the settings menu. In any other program you will have such options in the window menu ,view or even in their own menu. no matter how you look, semantically dockers should not be there. (reason why i make my plugin to add them to the main menu)
if the person needs to open each menu to find an option, thats a ui/ux problem cause tells that either the menus are not clear enough or that the option is somewhere that doesnt make sense. look at what I9S said, 4 years using krita and he still opens the wrong menu i dont think this is an issue of not knowing the program.
the whole point of UI/UX is to make things intuitive to the user, making things easier accessible and more practical to use, look at blender they changed their ui and how some things work to how most other programs work which in turn made it much more accessible to new users. so sorry but i dont agree with this idea of “the user is not familiarized with it yet” for basic things like this.
Please excuse this side topic, but I think I was misunderstood/misinterpreted.
I’m not at all disputing that there could be more logical or better options for user interface design. Like the one this topic is about. I’m talking about a lack of initiative and curiosity.
When I was growing up, and even for the first 14 years of my life with computers, there was no (publicly available) internet or forums like this, you had to help yourself, or you would have had to call the program author (if they offered phone support at all) or more likely write a request for help and wait for them to answer the letter (not email but snail mail). Phone support was available for high-priced commercial software, or when companies paid for it.
And since this was the case, we used to deal with the software we used in great detail.
To stick with the example, the dockers can be found by anyone looking once in each menu in turn, and that’s even though there are places that make more sense. You just have to do it. But the zeitgeist is obviously different today. Helping yourself, being proactive, seems unfashionable or even frowned upon.
And that’s what I was scoffing at.
I don’t want to commit about the solution on behalf of the devs as I am not one, I am saying they will “probably” have a solution. But I wanted to tell that they know about the issue. Let us wait to hear back from them and get some clarity.
Thank you for all the input about this option. I will think about what we can do about that. Just take it into account that this “feature” is not very easy to recover without introducing numerous bugs, so we consider it as “quite a significant project” at the moment.
For those who want it, Lunar Kreatures created a plugin that returns this functionality (do not take into account the visibility of the layer in the history.)
Hey,i’ve kept using krita 4.4.8 since this has been implemented because undoable layer states is a huge dealbreaker for me. I know that the devs are working on it and that it is difficult to implement this feature as a switchable option ,but what about releasing a standalone krita version with the old behaviour, could that work? I don’t know how difficult this is ,i’m not exactly experienced in coding.
I did.But that plugin is not perfect and requires some additional shortcuts + that it’s laggy,and it’s a shame that we must rely on a user made plugin for such an important feature.
As far as i’ve seen ,implementing undoable layer states solves a non-destructive problem created by the user.
Taking layer states into account though poses mechanical problems that cannot be worked around such as :wiping redo history.
I think one solution instead of making this a switchable feature is to revert back to the old behaviour and to show a warning everytime you undo activity done on a hidden layer
@dkazakov was interested in this. From what I know the older method had issues and bugs where people lost data. I know it is tiring to wait and a game of patience, but I think there will be some remedy for this in future.
As for making an alternative version I think you would need to maintain a fork of krita and revert the commit that introduced this change and also keep on adding commits for new changes in current krita and build an executable for each release. It will quiet a daunting task. And considering how this change is it will also lead to some issues where new changes touch the same code of layer stack.
Yes, the old version with non-undoable layer visibility caused data-loss level bugs, so we just couldn’t keep it easily. The problem is that “image-modified” state is tightly linked to the undo history, and saving operation is linked to the “image modified” state. So occasionally you could easily end up with delivering your customer an image with technical layers still visible.
To fix the issue properly we would need to implement a “forked history” functionality, which is possible, but rather difficult.
Hello