I'm not sure this a good idea: this breaks one's workflow if you want to set up a new group and add a layer to that empty group.

Yes, I agree, it breaks this workflow and I actually didn't think of the case where the group is empty. I think this should be an exception, a separate case so we have:

empty group selected -> insert button clicked -> new layer should go in the group
non-empty group selected -> insert button clicked -> new layer should go above group

So the reason is should go above group is otherwise you'd have to do it in two steps: insert layer in group at the top (which you can already do if you select the top most layer inside the group) then move the layer above the group via say ctrl+pageup. It's a minor change, but I personally think it's fine to insert layer above group when you have a group selected because we already have an option to insert at the top most position as mentioned. And it just becomes a bit annoying if you want to insert a layer immediately above the group which I myself do a lot of time.

This remark actually came from someone else but it just pushed me to look into it and do the modification.

So I agree, if group is empty, new layer should be inserted inside the group, but only then.

No, the more I think about it, the more this seems wrong to me. It's not the way things have ever worked, nor does it work like this in other applications.

I think the current functionality is ok for now too. @razvanr is right that there is one workflow that is going to be inconvenienced with how it works now. I think this change is going to swap what the inconvenience is going to be . Usually things like this need more brainstorming with all the artists before making a patch. Everyone uses layers differently, so it is a really tricky area to do. There are going to be some people unhappy no matter what solution we end up choosing.

There might be another solution out there that will work for what @razvanr wants, but this probably isn't it. He stated the problem pretty well which is a good start a lot people don't do. We probably just need a better solution to it instead of what is proposed here.

@scottpetrovic there's no point in working on changes if I don't present at least a bare minimum case for them :).

The more I think about it I tend to agree with you as well. Just in my experience is that inserting above the group layer is a much more common operation than one might expect, but my view might be biased on this as my workflow does rely on this quite a bit. This little modification I made here was very briefly discussed about a month and a half ago or something like that via IRC and @rempt gave the go, but we never really discussed the deep implications. And since then I just had it on hold until now.

There's another operation that isn't so easy to perform: insert layer at the very bottom of the group. It's a two-step process as well since all layers are inserted above the current one (with the exception of having a group selected): you have to insert the layer above the bottom most layer in the group and move down OR insert the layer just below the group and move up.

So again, these might be so minor that at the end of the day they might not even make any difference. The "insert above group while having selected the group layer" got to my attention when someone else mentioned it, either via IRC or in a bug (but I couldn't find the bug so it's more likely IRC). They probably forgot about it by now.

In any case we could discuss this further if you core devs seem interested about the conversation and I'm happy to try and work on it, but if you feel it's more hassle than not and not very useful than I'll just close this diff :)

In https://bugs.kde.org/show_bug.cgi?id=399103, a modifier is suggested.

Hi Razvan,

I'm not sure whether you're tracking the relevant bug report as well (https://bugs.kde.org/show_bug.cgi?id=399103), but the suggestion made of making the action depend on the collapsed or open state of the group is one I like a lot, and a patch along those lines would be great.