Let's track the arrow issue in: https://bugs.kde.org/show_bug.cgi?id=415049

Still works for Adwaita:

In D25814#574389, @ngraham wrote:

In D25814#574380, @ndavis wrote:

FWIW, Adwaita Dark uses dark separators, but GNOME doesn't use nearly as many icons as we do.

To me, this image really shows how good the dark separators look. I don't think the fact that our UIs are more icon-heavy is a significant factor here. Unlike GNOME, we tend to use ToolButtons, which have no outline until hovered over. So in fact there are probably fewer lines with the separator color in our Toolbutton-heavy UIs compared to GNOME.

Thanks again :)

In D25822#574271, @ngraham wrote:

Nice. Does this fix or obsolete D25699?

Thanks! It will be easier to test now.

Yeah, PC2 ToolButton has this so it loads the arrow: https://github.com/KDE/plasma-framework/blob/master/src/declarativeimports/plasmastyle/ToolButtonStyle.qml#L110

I agree, I think brighter and slightly less saturated colors would look nice.

I think this is useful. Every once in a while we get opinionated people who think light separators are awful in the Breeze Dark scheme (I would hate dark ones on the other hand) or even some ricer people who want to turn off separators (which they could do now by matching it with window color I guess).

This is the wallpaper in question:

In D25699#573713, @fvogt wrote:

The check for the prefix was added in bf1d1cc6b2ad37cb586f44b56fa2438ed3a5dbfc, while the control.flat one got added much earlier.

The labels are visible again with just the control.flat condition, but the prefix one might be needed as well for non-breeze themes.

There's a part missing though, the triangle (visible on https://openqa.opensuse.org/tests/1105226#step/start_wayland_plasma5/21) is gone. That seems to be a feature lost with PC3 :-(

In D25340#563400, @ndavis wrote:

This diff is against commit 467d721cc96258b54048c0dd1508d16e03c0cd55, which isn't in git master. Do I actually need that commit for this patch to work?

Yeah, that might not be a bad idea. Our GridDelegates do not support more than 1 line of text right now if I'm not mistaken though.

+1 from me as well for the reasons listed in the commit message

In D25728#572350, @manueljlin wrote:

But that style of line / divider was going to be after the toolbars too, like kirigami apps, so removing it just would make that inconsistent later on. The divider needs to be inside the application itself to make this possible, instead of in the titlebar.

If it's possible, fixing the color scheme and making it configurable should probably be the way to go.

In D25726#572255, @ngraham wrote:

5.17 I say

add space before final )

define condition without creating a variable

In D25728#572043, @anthonyfieroni wrote:

So with the patch is it drawn when it is ticked in window decoration?

In D25728#572036, @anthonyfieroni wrote:

Is that configurable (Window decorations -> ^ Draw separator between titlebar and a window ?

don't break the sidebar

So we also fix this by setting:

I just realized this kills the sidebar when there's more than 1 kcm under a category :(

In D25728#571848, @ngraham wrote:

But... the "Before" image looks better. :/

Having the titlebar blend with the window kind of requires that nothing wants to be touching the titlebar, or else it just looks bad IMO. Personally my preference is to restore consistency by moving in the opposite direction by always showing a separator between what I'm calling the window's "tools area" (which consists of its titlebar + menubar if visible + toolbar if visible). That's what T10201 is all about and I had thought we had some agreement on that. If we land this patch, then there's no separator below the Tools Area for these windows, going against the goal of T10201.

In T12308#212465, @ngraham wrote:

I am absolutely in love with the dark version that has the dark separators. I think I might actually use a dark theme if it used dark separators like that!

Hi, this patch triggered a bug in icon view: https://bugs.kde.org/show_bug.cgi?id=400876

I like the idea of raising the contrast effect to 0.3, but if people object to that we should just keep it at 0.2.

onToggled instead of onClicked

What about Fira Sans SemiBold like this?

use Layout.preferredHeight/Width instead of implicitHeight/Width

Ah right, it will complain about a non-existing property.

With this patch:

In D25581#568711, @broulik wrote:

Can you verify how the widgets QTabBar behaves in this scenario?

My impression is that the rounding is currently just faked by the shadow. So when the shadow gets lighter, it becomes more obvious that the object itself isn't really rounded.

In D25584#568669, @ngraham wrote:

Feels like at this point we should just break down and create an actual TabView control all at once. :p

In D25582#568654, @ngraham wrote:

A saner hack indeed. Probably 5.17-worthy. Can you apply the same thing to the plasma-pa KCM, if it also needs it?

P.S what would make this perfect is removing the border in the qqc2 styling of tabbars.

As far as I can tell theme names don't always match the folder names they reside in.

minor indentation fix

I'm thinking users might use PNGs with transparency for their avatars, which means they might not want to have a border around it.

simpler dependencies list

Maybe I shouldn't list all those dependencies like that. The list would probably get outdated soon and maybe the deps can be listed more abstractly so there's fewer lines.

Friendly ping.

I like bottom left. I think that highlight effect is more appropriate as it indicates that some category has been selected. The one in the top left feels more like the effect when you hover over items in a list (but nothing is simultaneously open).

I don't think legibility would be an issue, but it's true this wouldn't be consistent with other windows. The idea to also be able to control Konsole's transparency via some global setting sounds good.

and I should feel bad.