I tried to address the most recent comments:

In D25814#574395, @filipf wrote:

Already asked in VDG, but repeating here: how would we handle dark separators on really dark color schemes?

This is the most downloaded color scheme and it won't work well with dark separators: https://store.kde.org/p/1294011/

wait scratch that, it does work. I had to remove the 22-22- prefix, which is what you normally need when you have multiple icon sizes.

In D25815#574394, @vinzenzv wrote:

In D25815#574216, @ndavis wrote:

Here's one way to make a nice looking trapezoid in the Breeze style. I started by making a stroke with end points in the middle of pixels and the other settings I mentioned in my first comment. Then I converted it to a path and I added a 2px high rectangle to increase the thickness of the bottom part.

So as you already built it the icon is finished, right?

In D25820#574119, @ndavis wrote:

Good start! The lens flare looks upside down

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.

In D25815#574216, @ndavis wrote:

Here's one way to make a nice looking trapezoid in the Breeze style. I started by making a stroke with end points in the middle of pixels and the other settings I mentioned in my first comment. Then I converted it to a path and I added a 2px high rectangle to increase the thickness of the bottom part.

In D25814#574380, @ndavis wrote:

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

In D25814#574356, @hpereiradacosta wrote:

I meant: do the "light" (with window text color) toolbar icons play well with dark toolbar separators as opposed to current semi-light toolbar separators

Thanks again :)

Updated all the things.

I'm not sure what you mean when you wonder how it would play with monochrome icons. It should have nothing to do with them unless you embed stylesheets in the SVGs to use the separator color in breeze icons.

In D25822#574271, @ngraham wrote:

Nice. Does this fix or obsolete D25699?

Thanks! It will be easier to test now.

In D25814#574250, @hpereiradacosta wrote:

• You should add toolbar separators, tabboxes and group boxes to that. For toolbar separators, I wonder how this would play with monochrome (color-themed) icons.

@dfaure Ping

Good idea, done in 912ec731b8bd9eca12ae21920c81bcddfb46622b.

Nice. Does this fix or obsolete D25699?

In D25814#574197, @ndavis wrote:

In D25814#574160, @davidedmundson wrote:

Can we clarify what separators we're referring to.

Frames around UI elements and horizontal/vertical lines that separate UI elements.
These are the most common examples, but probably not absolutely everything:

In D25720#573926, @elvisangelaccio wrote:

In D25720#572291, @ngraham wrote:

Though Dolphin seems to have some kind of local hack to make Shift+delete work for file deletion. But it doesn't work for Cut. It's all pretty messy.

Yes it's messy but it's Microsoft fault since they chose to use an already used shortcut for another thing and we are doomed.

Some years ago I submitted the very same patch and it eventually led to 8eabbf6725386e716b7536c71a9181dfe5d959f0 in kxmlgui, which automatically handles the conflict for those few apps that need both actions (dolphin, gwenview, etc.)

(Too bad reviewboard was shutdown, I had to dig in my mail to find it :/)

So imho #414799 should be closed as intentional.

So the background here is that we've gotten a new VDG designer who produced mockups of Breeze dark with dark separators, and some people absolutely fell in love with them, while other people hated them. We could not achieve consensus on moving to use dark separators for Breeze Dark, so there was a desire to offer people that choice. It occurs to me that we could put this in the Breeze style's own settings, if it's strictly necessary to expose this to users. Personally I would prefer to just make a decision on separator colors one way or the other rather than making it explicitly configurable (dark separators FTW :) ).

All right. Thanks for the history!

various fixes suggested by dfaure

Yep, still looking for primarily design input.

In D25814#574197, @ndavis wrote:

In D25814#574160, @davidedmundson wrote:

Can we clarify what separators we're referring to.

Frames around UI elements and horizontal/vertical lines that separate UI elements.
These are the most common examples, but probably not absolutely everything:

Here's one way to make a nice looking trapezoid in the Breeze style. I started by making a stroke with end points in the middle of pixels and the other settings I mentioned in my first comment. Then I converted it to a path and I added a 2px high rectangle to increase the thickness of the bottom part.

In D25815#574150, @broulik wrote:

I chceked transmission git code and the icon name it uses is actually transmission-tray-icon, so you want to have a transmission.svg file and the "id" to be transmission-tray-icon, then it should work: https://github.com/transmission/transmission/blob/master/qt/MainWindow.cc#L302

I liked the original design with the trapezoid shape better TBH. The square one does indeed look quite "grave-like"👻👻 and IMO isn't identifiable as Transmission anymore.

In D25814#574129, @hpereiradacosta wrote:

Few more comments on this:

• general: you will never be able to make all the opiniated people happy, and you have to draw a line (otherwise your code will become bloated, buggy, and unmaintainable)
• regarding this specific case: many widget style will not implement this new color. For those this will just generate bugs reports: why is my color scheme not respectd ?
• some widget styles (oxygen at least, but I'm sure there are others) use two colors for frames and separators, to mimic shadows or relief effects. Adding one single color for this will not fit such schemes.
• in the end if you need an extra color for a given theme (be it future-breeze or whatever), there is also the possibility to add it as a extra option for this specific theme, rather than forcing it to kcolorscheme and imposing it to all styles (or making kcolorscheme broken for all the styles that wont use it). This is how window decoration shadows and glow were handled to oxygen. I think this change will break more things than it will fix, especially if the fix is to make some opinionated people happy.

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

In D25814#574160, @davidedmundson wrote:

Can we clarify what separators we're referring to.

Had to revert the commit, it broke with GCC.

Can we clarify what separators we're referring to.

I also agree with the concerns rised by Hugo. An application will use various frame primitives, and the style decides how to draw them. It doesn't belong in the API, though (but neither do Focus and Hover colors).

I chceked transmission git code and the icon name it uses is actually transmission-tray-icon, so you want to have a transmission.svg file and the "id" to be transmission-tray-icon, then it should work: https://github.com/transmission/transmission/blob/master/qt/MainWindow.cc#L302

Hugo's arguments make sense, removing my approval.

Few more comments on this:

• general: you will never be able to make all the opiniated people happy, and you have to draw a line (otherwise your code will become bloated, buggy, and unmaintainable)
• regarding this specific case: many widget style will not implement this new color. For those this will just generate bugs reports: why is my color scheme not respectd ?
• some widget styles (oxygen at least, but I'm sure there are others) use two colors for frames and separators, to mimic shadows or relief effects. Adding one single color for this will not fit such schemes.
• in the end if you need an extra color for a given theme (be it future-breeze or whatever), there is also the possibility to add it as a extra option for this specific theme, rather than forcing it to kcolorscheme and imposing it to all styles (or making kcolorscheme broken for all the styles that wont use it).

This is how window decoration shadows and glow were handled to oxygen.
I think this change will break more things than it will fix, especially if the fix is to make some opinionated people happy.

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).

Good start! The lens flare looks upside down and the icon needs more pixel alignment. I feel like the red/green/blue colors of the center area are a bit too dark as well.

@hpereiradacosta, Fair points and I'm glad you spoke up. JFYI, I'm in no rush to land this and I will consider reserving this change for KF6 if experienced KDE devs think that is best.

Would also be good to have the opinion of @cfeck on this.

In D25815#574111, @vinzenzv wrote:

In D25815#574103, @ndavis wrote:

The actual name of the icon is transmission, so you would have to rename the file to that and add id="transmission" to the group. Since this is a desktop theme icon, you would also have to add an invisible 22x22 rectangle to the group.

However, even after doing all that myself, I can't get this icon to work. I'm not sure why. It doesn't work with transmission-qt either.

I rebuilt the whole icon taking the SVG of Konversation. Maybe I messed up something with the initial one.

In D25815#574103, @ndavis wrote:

The actual name of the icon is transmission, so you would have to rename the file to that and add id="transmission" to the group. Since this is a desktop theme icon, you would also have to add an invisible 22x22 rectangle to the group.

However, even after doing all that myself, I can't get this icon to work. I'm not sure why. It doesn't work with transmission-qt either.

Adding new entries to the kcolorscheme should be done with a lot of care, because it could be seen as some sort of API break for existing colorscheme, as soon as you start using this color in the widget style: you would need a fallback implementation, for all the colorscheme in the open which do not implement this particular color. These kind of additions happened a lot whith gtk3 css style and resulting of overall unhappiness and distrust from theme/color scheme developpers. This also increases the complexity of the code and difficulty to maintain.

Okay, gotcha. I played around a bit but am not too satisfied yet. I tends to look like a grave...

The actual name of the icon is transmission, so you would have to rename the file to that and add id="transmission" to the group. Since this is a desktop theme icon, you would also have to add an invisible 22x22 rectangle to the group.

Hey, thanks for the patch!

Very nice! You even embedded the stylesheet. However there are a number of lines and corners that would look better aligned to grid lines or points. You don't have to always to this, but in general it's better to. Also the Breeze icon style generally has pointy corners rather than rounded ones.

• Comments

Ping?

In D25599#573581, @sars wrote:

Yes it works :)

(I added QLocale::setDefault(QLocale(QString::fromLatin1(languageCode))); to the end of the if statement in initializeLanguages())

Hmm... For an application like Kate it is totally fine to set the language through kxmlgui, but kxmlgui is tier 3 while kcoreaddons and ki18n are tier1. Sure any application can use setDefault() to change the language of the plugin metadata, but that does not change the translation language in ki18n.

I think the proper solution would be to use the same mechanism in ki18n and KCoreAddons. If we use the env variable we need to change KCoreAddons and if we want to use QLocale we need to change KI18n to use QLocale.

Would this work for you?

CI = not happy

Code looks OK. No opinion on usefulness though.

• update @since version

Makes sense.

In D25720#572291, @ngraham wrote:

Though Dolphin seems to have some kind of local hack to make Shift+delete work for file deletion. But it doesn't work for Cut. It's all pretty messy.

• change minimized bg opacity to 8%

This feels so close to perfection! But now it feels like the minimized bg is too subtle, maybe. I wonder if 0.08 opacity for minimized tasks might help. Or maybe I'm just torturing this poor patch to death...

Nice that you take care of that stuff.
Could you enhance the CMake test file, too, to cover some of the new stuff?