@tiar I also like the buttons on the stack, but the main reason to put them on a toolbar is that, if you have a lot, then the awfulness will be there. Csp, with all the layer options, cannot put the icons directly there.
For example, I want to implement the reference layers feature (the lighthouse button in csp) an it would be one more icon.
Edit: and if you have layer fx, it is one more icon already.
I could agree with throwing away inherit alpha, since itās usually set once and then forgotten about, but I think locking and lock alpha, or at least locking, should stay. Itās useful when you for example want to use transform tool on a group layer but donāt want all layers to transform, or want to transform the layer but not the mask, or you want to prevent painting on the sketch layer etc., but then want to use it to add a little detail, and then lock it again - I think itās better with the easy access as it is now. Note that reference layers are usually set once and then forgotten too, so it could be just like Fx and inherit alpha only shown when active/activated for a specific layer.
However, that could be configurable. If we make icons in the folding area configurable, then it would need a bigger configuration dialog anyway.
I added an icon based on that in my mockup since it seems like a good function to implement in the future.
I also think it would be a good idea to have buttons that have more than one option, that is, a list of layer masks, for example.
That would save space.
Or we could make the toolbar static with all the buttons and configure which options should be shown on the stack. Kind of:
I see what you are getting at with the icons. I orefer accessibility, a dropdown also gives me that so thatās nice. Can we prevent misclicks on it easily? One way I could think of is to make it a drag handle to expand. Just like what you have on the left/ right side in docked dockers.
The hamburger menu may work for hiding these buttons, but is too tedious, so overall nice idea. And yeah, CSP looks terrible for this.
Configuralble icon buttons sounds nice too!
By the way, Iāll drop the reverse order now that I see people donāt agree with me on this. I partially misunderstood the request, sorry for the confusion.
Iāve already said why. Problem when working with multiple layers. If we are talking about serious work. These are dozens of layers. Alpha inheritance is enabled somewhere. Somewhere alpha lock, some layers just locked. Some groups in path through or alpha lock. And all this needs to be seen. Literally necessary. And if weāre talking about an studio work? One person passed the file to another. And the second one, in order to understand something, will also have to click almost every layer. And not to see the whole structure. Are you seriously suggesting switching layers one by one to find where I forgot to turn on inheritance? And all this in exchange forā¦ Layer names! Brilliant. Who cares? Prefixes. Colors. Arrangement in groups. The R button. These icons on a layers are a great solution among other software. You donāt make the layers cleaner. Youāre making them less functional. Thatās a big difference. Itās not like thereās something wrong with layers in Krita. The rest of the programs are bad with layers.
Many suggestions can be heard from users about the interface. But specifically this is not just useless, it is destructive.
So your only issue with this is visualizing which properties are activated on each layer? Or do you have more issues?
The layer would show the icons of the activated properties. So you could visualize like now what is activated and at the same time you could see the name better which, believe it or not, it is important for some people.
Though not necessarily part of the mock-ups, but as part of the layer docker redesign it would be great to consider double clicking to access layer styles. Or to access properties for file layers, fill layers and filter layers.
In the same way, double clicking the opacity slider (and sliders in general) to use type-input would also be nice QOL improvements. Iām so used to double clicking as opposed to right clicking, I doubt Iām the only one who learnt that habit.
Hereās the trash button (already in Krita) :
If you want to argue that it should be moved to the left or users should be able to choose their placement, youād get no argument from me.
Just reading the last posts, like a guy who walks past a window on the street, hears a conversation and talks to people on the other side of the window 
As an option maybe
On my side dragānādrop features are usually most a lost of time for me but, if a developer want to implement that I donāt care as long as the usual click method is still available 
Let user define UI could be interesting in some case butā¦
) then if users start to have different UI it will start to be really hard to provide helpGrum999
Thought of another solution with regards to trash button. If the Layer Docker is on the right side, then the trash button is closer to the left. If the layer docker is on the left side, then the other icons is closer to the right side.
Sorry, again I am slightly off-topic.
I think I am old-fashionedā¦
ā¦ I always use the shortcut.
Michelist
This topic strictly about moving buttons to top from layer list not the complete redesign . Please be on topic.
Going off topic leads to derailment of original topic. Please please think before posting anything. As you post one offtopic line people then reply to it and then suddenly the thread is about something else
19 posts were merged into an existing topic: Potential improvements to Inherit Alpha in Krita
Rather than staying stuck in the Windows 95 UX method of drag and dropping into the recycle bin, why not embrace a bit of modernity and allow users to swipe right on a layer with pen or finger to reveal a red trash can button that they can click or tap to delete the layer?
I donāt mind the regular trash can button (and I wouldnāt get rid of it) but if youāre wanting a faster way to delete without having to select the layer first, thatād be it.
I realize thatās a newfangled and barely tested method thatās only been in use for 13 years, but maybe people can catch on.
which is a shame i do like the ideas presented here and i wanted to comment on the mockups presented by tiar.
I agree, both parties presented their ideas anyway. i do think its more productive to debate the other ideas here
Yes, letās move on to the voting stage.
I will backtrack a bit on this topic cause i want to give my opinion on some of the ideas presented here
@tiar i was wrong, thats not configurable I confused it cause csp sometimes call things by the same name. though i want to show a more updated version of the layer docker in csp.
I also want to note that there are 2 lines, the second line with the trashcan can be moved to below the docker so only the first line is related to the layer. I also thought mine had less icons cause the icons seem to be smaller now.
Also for comparison this is how desktop medibang handles it:
I do like your porposal and yes i totally agree that layer styles should be more accessible. I also like the one proposed by SchrodingerCat post 18 as i feel the icons can be small
i think this is a good idea.
Sorry but i still dont see the issue.
Damn i was sure i made this to reply to wpfosh post, dont know why it didnt count, anyway reply to this post 26
But if these actions can affect multiple layers at once wouldnāt that be a plus? especially when dealing with multiple layers and groups? I think this is the biggest plus in having these outside the layer stack.
To illustrate this let me show what you can do in csp with this approach:
Wouldnāt this be more practical than having to enable that on each layer?
And it will be seen as Deif_Lou pointed out in the answer to you as these would still be shown beside the layer, also all these options would be in a static location if you need a visual representation of what we are suggesting check both tiar`s and mine posts that we share how other programs deal with that.
and with this i gave my opinion on what i wanted, sorry for backtracking the topic
I donāt mind moving the properties to the top, so long as thereās an option to still have them visible next to the layer. Moving them to the top is a great way to save space for people working on mobile devices or smaller screens, but itād be a punishment for those of us that have plenty of space for options on the right.
