Breeze theme evolution
Open, WishlistPublic

Description

The Breeze theme is great. But... it can be greater!

Over the years VDG has accumulated a rough list of changes we'd like to make to evolve the Breeze theme into the year 2019 and beyond. The goal is not to fundamentally change what Breeze is, but rather to improve on it and modernize it, while also learning from our peers, as applicable.

Here's the proposed list of changes:

  • Turn off window borders by default: T8707
  • Separate views from one another with with single-pixel lines rather than putting everything in a frame: T11661
  • Define a window "Tools Area" that consists of the titlebar, menubar, and toolbar (or any combination thereof). This area has a line at the bottom that visually separates it from the content area below, and its background is a darker shade of gray than the typical window color. - Under discussion: T10201
  • The Tools Area's background becomes lighter or desaturated for inactive windows: T10201
  • Window shadows become slightly smaller for inactive windows: https://bugs.kde.org/show_bug.cgi?id=393238
  • Make settings windows' left category sidebars have a white background and a single-pixel separator between them and the content view: D20908
  • Move away from putting the main content view in a frame, and instead frame it with what surrounds it (window edges, Tools Area, left sidebar, etc)
  • Use all colorful icons for settings windows' categories - In progress: T10165
  • Use colorful icons for small-sized places, devices, and mimetype icons - under discussion: T10870
  • Make the checkbox's checked state look like a checkmark: T10997

Note that as a part of thie effort, I do not want to try to round the bottom corners of the windows when No Borders is in use. This idea is too controversial and has the (slight, but real) potential to interfere with applications that put interactive elements in the bottom corners. People who want to accomplish this anyway can use https://github.com/alex47/KDE-Rounded-Corners.

Here are some crude mockups of how it would look:

Dolphin window:

Inactive Dolphin window;

A Plasma settings window:

Basically it should look kind of similar to https://github.com/Luwx/Breeze-Kvantum/blob/master/Screenshot.png

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes
cblack added a subscriber: cblack.Jun 7 2019, 12:10 AM

Not sure if this is the right thread, but here goes.

I feel like while we're tweaking Breeze's design, we should take a look at the colours in some more detail.


The same accent colours are shared between the default Breeze Light & Breeze Dark themes. However, the same colours in the Breeze Dark themes have a greater "pop" to them, and this is especially noticeable in applications that use accent colours on large surfaces. (See: Virtualbox)

Making the colors slightly paler or less saturated increases contrast against the dark background while also making their pairing with the dark background feel more similar to the pairing of their brighter equivalent with the light background.

Discover w/ Breeze Dark & Paler Colors

Discover w/ Breeze Default

Discover w/ Breeze Dark

Notice how the paler version visually appears more similar to the light version despite the light version and the default version technically being based off of the same colour.

filipf added a subscriber: filipf.Jun 7 2019, 12:35 AM

^ This is definitely something we should also talk about. I wholeheartedly agree that we don't need to have the exact same colors in Breeze and Breeze Dark. The blue highlight color in particular can be quite blaring in Breeze Dark. That's why I toned it down in this sort of beta of what a new Breeze Dark might look like: https://www.pling.com/p/1304099/

But the thought of paler colors didn't cross my mind, seems interesting. I'll have to play with that once I get to testing colors again.

I created T11052 to discuss the idea of an Accent Color system and related components for Plasma.

mglb added a comment.Jun 10 2019, 10:32 PM

Here's another idea I've heard bandied about: create new "whitespace" and "expanding whitespace" items that can be added to toolbars so it's possible to have layouts of toolbar buttons that are centered or justified rather than left-aligned, and that use whitespace to separate logical groups rather than vertical separators. macOS has had this for ages and it results in some very aesthetically pleasing toolbars IMO:

Another implementation idea for the same effect, with support for multiple toolbars (per line):

  • Split each toolbar slot into left/center/right slots (or top/middle/bottom)
  • Align toolbars depending on which slot they are put it

Kind of like panels, but with alignment instead of expanding.

However, new implementation of ToolbarAreaLayout (i.e. code for docking toolbars and moving/aligning them) would be needed.


As for colors, making primary/selection color a bit darker would be awesome. White text on plasma blue has low contrast.
Alternatively, the text color can be changed to black, but this doesn't look so cool.

In T10891#187828, @mglb wrote:

As for colors, making primary/selection color a bit darker would be awesome. White text on plasma blue has low contrast.
Alternatively, the text color can be changed to black, but this doesn't look so cool.

This is probably a pretty easy fix that we could get in very quickly. Personally I'm partial to the more subtle pastel blue used for Plasma selection highlights and as the background for the informational KMessageWidget/Kirigami InlineMessage messages, where the text stays black. As another bonus, adopting this color would reduce the unnecessary visual distinctiveness between Plasma and KDE apps.

In T10891#187828, @mglb wrote:

As for colors, making primary/selection color a bit darker would be awesome. White text on plasma blue has low contrast.
Alternatively, the text color can be changed to black, but this doesn't look so cool.

This is probably a pretty easy fix that we could get in very quickly. Personally I'm partial to the more subtle pastel blue used for Plasma selection highlights and as the background for the informational KMessageWidget/Kirigami InlineMessage messages, where the text stays black. As another bonus, adopting this color would reduce the unnecessary visual distinctiveness between Plasma and KDE apps.

I would agree. Long ago, I made some mockups where I discussed the state of highlights in KDE (a much older version) and noticed the color inconsistency across apps, not only that, also noted the shape and application differences. If we find a way to make them more consistent, we should go for it.

pettke added a subscriber: pettke.Jun 11 2019, 11:49 PM

Since I saw those crude mockups, I've been changing it with the suggestions I wanted to make plus others. It takes some pages taken from how other DEs do their things and some of my own preferences, while at least still trying to not deviate too wildly from the Plasma look. I've also combined it with some suggested changes to the current system settings application.

{F6844666}

Concerning the more compact buttons (as well as combo boxes etc.): they used to be more compact in the Oxygen era, but IIRC they were enlarged with the development of Breeze to make them more touch friendly and faster to interact with in general (see https://en.wikipedia.org/wiki/Fitts%27s_law)

And what would happen to menus? How will that centered toolbar look with menus on the left?
How it will work with KDevelop for example?


Or Krita?

Krita actually already provides whitespaces and expanding spacers for toolbar configuration in addition to the regular line separators. If you take a closer look at the Krita screenshot, in the toolbar there is one element at the right separated from all the other ones by an expanding spacer.

Besides, I'd also like to +1 the "hybrid separator" which switches between line and spacer depending on the available space :)

ngraham updated the task description. (Show Details)Jun 14 2019, 4:43 PM

Should T10243, which is about redoing many Breeze icons, be a subtask of this as well?

@ngraham I have been tracking this for a while but finally created an account to contribute some comments. As a newcomer to KDE from gnome-based desktops I am reliant on apps like firefox and thunderbird. The GTK Breeze theme has some minor usability issues with tabs in these apps. See these screenshots:

Firefox is decent with Breeze, but it is hard at quick glance to visually separate the active tab from the other tabs. There is a blue bar at the top, but better would be to darken the color of the inactive tabs. It would help to not be so disorienting. Note I am using "Firefox Containers" which is why all the blue lines are at the bottom of the tabs.

Thunderbird is harder to differentiate the tabs. There is no line at the bottom of inactive tabs so it is really hard to tell what is active and what isn't: again only the blue line at the top of the active tab lets you know that, but at quick glance it is hard to pick up.

Thanks for looking at things that will make Breeze the "go to theme" for cross-toolkit apps to give them the unified look that Linux deserves!

ngraham added a subscriber: mthw.Jul 15 2019, 7:29 PM

I sure hope so! Yeah, we're working on that particular issue too. @mthw may be interested in this!

There's something I've noticed that's inconsistent between applications - how loading is represented. There's not really any consistency at all, excluding Kirigami applications.

Some examples:

  • Dolphin blanks the view while loading a directory
  • Kate also remains blank, but sets the cursor to a loading animation
  • Kirigami applications use a spinning view-refresh icon in their list views when loading (see: Discover and its tendencies to load indefinitely)
  • KMail uses plain loading bars wherever it feels like it
  • Systemsettings5 freezes the view and sets the cursor to a loading animation
  • KDE Help uses freezes the view and shows a message in the bottom left corner
  • The icon selection dialog used in places such as editing application entries freezes the view, shows a loading bar, and sets the cursor to loading.

There's plenty more inconsistency, but there's too much to list all in a single place.

mthw added a comment.Jul 16 2019, 8:42 AM

@ngraham I have been tracking this for a while but finally created an account to contribute some comments. As a newcomer to KDE from gnome-based desktops I am reliant on apps like firefox and thunderbird. The GTK Breeze theme has some minor usability issues with tabs in these apps. See these screenshots:

Firefox is decent with Breeze, but it is hard at quick glance to visually separate the active tab from the other tabs. There is a blue bar at the top, but better would be to darken the color of the inactive tabs. It would help to not be so disorienting. Note I am using "Firefox Containers" which is why all the blue lines are at the bottom of the tabs.

Thunderbird is harder to differentiate the tabs. There is no line at the bottom of inactive tabs so it is really hard to tell what is active and what isn't: again only the blue line at the top of the active tab lets you know that, but at quick glance it is hard to pick up.

Thanks for looking at things that will make Breeze the "go to theme" for cross-toolkit apps to give them the unified look that Linux deserves!

I see two solutions for this problem:

  1. Use CSDs and fix text color on non-selected tabs (something I am trying to fix - but might be a bug in Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=1461650)
  2. Change Breeze theme so it has the same look with CSDs and SSDs (and also fix that bug)
In T10891#191854, @mthw wrote:
  1. Use CSDs and fix text color on non-selected tabs (something I am trying to fix - but might be a bug in Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=1461650)

For Firefox and Thunderbird, CSD vs SSD is something that the user can determine, so we need to make sure both work. Also we can't force one in the theme.

  1. Change Breeze theme so it has the same look with CSDs and SSDs (and also fix that bug)

Generally that's the idea, but this is unfortunately not easily possible on X11. On Wayland there's hope though.

ngraham updated the task description. (Show Details)Jul 25 2019, 5:47 PM
johan.boule added a subscriber: johan.boule.EditedJul 28 2019, 2:21 PM

TLDR: Where would you recommend me to go if Breeze is not my cup of tea?

I don't know whether Breeze is still going to be the default theme when I upgrade, but I desperately hope there's gonna be a few very-select other well-maintained themes available without me having to crawl amongst the thousand random themes downloadable on external sites to find one that makes sense. And the crux here is being very-select. We don't need many themes, we just need three or four good ones. The previous version of KDE Neon unfortunately did come with 3 themes, which is enough, BUT, none passed my criteria of what makes a quality one. One of them even was named in a way to make the user not ever willing to select it because it referred to an operating system that you certainly don't want to use. And so I had to spend quite some time fixing hundreds of badly combined settings to make something workable. I'm looking for themes that are "classic" rather than "modern", by which I mean aimed at productivity and clarity of the information displayed rather than seeking some futile beauty. This is not painting, not art, this is efficiency to transmit information from the screen to my eyes, and the brain that's behind.

I hope there are some other people who understand what I mean and are fighting to put the good forgotten rules back in place.

Once you've done that, you seldom have to touch a theme anymore. It can stay the way it is forever unless you've got new technical elements to account for.

johan.boule added a comment.EditedJul 28 2019, 2:56 PM

FTR, the "Breeze" color palette proposed in Konsole is obviously not workable.
For the most obvious breakage: look at any manpage and you'll see (or won't see actually) that bright and dark text are indistinguishable!
You need to stick more closely to the standard, and only slightly adjust it.
Before you release a theme, check all combinations of colors to make sure there are distinguishable from each others (fg, bg, bright, dim).
I feel stupid for having to mention that, but, heck, I also feel that if I don't do it, you're gonna forget to check that again!

Note: the Breeze palette is not the only broken one amongst the default ones: there all are, except the "Linux" one and the "Black on White" and "White on Black" ones (which presumably are XTerm's or ECMA-48 standard, sanely crafted ones).

@johan.boule you are talking about two things if I understand you correctly: inefficiency and inconsistency/bugs. If there isn't an issue open for the konsole issue, you should open one or join the discussion because everyone agrees that manpages should be readable. As for efficiency: where do you feel that Breeze is lacking compared to "classic" themes? Maybe there is a way of improving that too. Glad that you decided to join the discussion.

TLDR: Where would you recommend me to go if Breeze is not my cup of tea?

The Kvantum theme engine seems like a popular alternative, although the engine's themes don't work as well with Qt Quick apps as it does with Qt Widget apps. Oxygen still exists. Fusion is the Qt Widgets theme provided by Qt and it's decent.

I don't know whether Breeze is still going to be the default theme when I upgrade

It will, unless your Linux distribution sets a custom default theme.

but I desperately hope there's gonna be a few very-select other well-maintained themes available without me having to crawl amongst the thousand random themes downloadable on external sites to find one that makes sense. And the crux here is being very-select. We don't need many themes, we just need three or four good ones. The previous version of KDE Neon unfortunately did come with 3 themes, which is enough, BUT, none passed my criteria of what makes a quality one.

I don't know about other KDE developers, but I'm not going to be working on any other widget theme. 3 or even 4 is quite a lot. KDE already has 2; Breeze and Oxygen. Oxygen doesn't get much development, but it still works.

The rest of this is off-topic, so please make another task if you want to continue this conversation. I'll still reply to save you the trouble of making a task in case a single answer is enough to satisfy you.

One of them even was named in a way to make the user not ever willing to select it because it referred to an operating system that you certainly don't want to use.

I'm guessing you mean Windows ;)

And so I had to spend quite some time fixing hundreds of badly combined settings to make something workable. I'm looking for themes that are "classic" rather than "modern", by which I mean aimed at productivity and clarity of the information displayed rather than seeking some futile beauty. This is not painting, not art, this is efficiency to transmit information from the screen to my eyes, and the brain that's behind.

I hope there are some other people who understand what I mean and are fighting to put the good forgotten rules back in place.

Most of the user made Kvantum themes are inspired by Apple and Google. You might find a few "classic" themes, but then you're back to searching around. In Fedora and openSUSE, you can get quite a few classic themes from a package called libqt5-qtstyleplugins. I think it includes Plastique (KDE3), Cleanlooks, Motif and CDE themes (If you want to go extra classic). If that's still not good enough, you can use the GTK2 theme engine, set a GTK2 theme that looks like what you want and Qt apps will follow that look.

FTR, the "Breeze" color palette proposed in Konsole is obviously not workable.
For the most obvious breakage: look at any manpage and you'll see (or won't see actually) that bright and dark text are indistinguishable!
You need to stick more closely to the standard, and only slightly adjust it.
Before you release a theme, check all combinations of colors to make sure there are distinguishable from each others (fg, bg, bright, dim).
I feel stupid for having to mention that, but, heck, I also feel that if I don't do it, you're gonna forget to check that again!

Note: the Breeze palette is not the only broken one amongst the default ones: there all are, except the "Linux" one and the "Black on White" and "White on Black" ones (which presumably are XTerm's default).

I already have my own custom version of the Breeze Konsole theme that's made to work well with custom shell prompts that use lots of colors, so maybe we should just use that. I made it before I was a KDE developer and kind of forgot about it even though I use it every day.

johan.boule added a comment.EditedJul 28 2019, 3:32 PM

@lavender By inefficiency, I mean usability, being brain-friendly.

Breeze, particularly its dark variant, as a whole, is a theme that wants to wash-out any visible cue about what are the discrete elements on the screen, probably for debatable aesthetic reasons.

So much that, for example, with the default settings, my brain ended up having a hard time seeing the limits of the windows when they are overlapping in certain ways. I would start merging two windows in my brain and have to fight the confusion by brain analysis, which, accumulated over hours of usage would just make me feel tired.

I can also mention I feel quite disabled in front of Konsole's tab. It's physically impossible for me to tell which one is selected.

Also, even after a year or two of usage, i'm still unable to tell by looking at the task bar which window is the focused/active one: the concept of having windows look like tab with their thin blue line telling which one is selected just doesn't imprint in my brain. What my brain see prominently is the background of the elements in the taskbar, but this merely indicates whether the windows are minimised.

I can't fight such brain issues no matter what effort I put in, and I'm probably not alone.

ndavis added a comment.EditedJul 28 2019, 3:58 PM

@lavender By inefficiency, I mean usability, being brain-friendly.

Breeze, particularly its dark variant, as a whole, is a theme that wants to wash-out any visible cue about what are the discrete elements on the screen, probably for debatable aesthetic reasons.

I agree, Breeze Dark really needs some new colors, particularly the selection and hover colors. I'm not sure it's even like that for aesthetic reasons.

So much that, for example, with the default settings, my brain ended up having a hard time seeing the limits of the windows when they are overlapping in certain ways. I would start merging two windows in my brain and have to fight the confusion by brain analysis, which, accumulated over hours of usage would just make me feel tired.

That might be because the colors are dark and the shadows are just more dark (black). I don't think there's anything that can be done about that and you should probably stick to light themes.

I can also mention I feel quite disabled in front of Konsole's tab. It's physically impossible for me to tell which one is selected.

That's a fair point. The contrast between background and selected tabs isn't very noticeable in some cases. It would probably be a good idea to address that. I feel like I've seen tabs with underline focus decorations, but I can't figure out how to get those, which isn't a good sign.

Also, even after a year or two of usage, i'm still unable to tell by looking at the task bar which window is the focused/active: the concept of having windows look like tab with their thin blue line telling which one is selected just doesn't imprint in my brain. What my brain see prominently is the background of the elements in the taskbar, but this merely indicates whether the windows are minimised.

Yes, I kind of agree that the way the taskbar's visuals work don't make a lot of sense. Perhaps they should be more like the sidebar visuals I've been working on: https://i.imgur.com/N6FmN8K.png

I can't fight such brain issues no matter what effort I put in, and I'm probably not alone.

I understand and I think your concerns are valid.

That might be because the colors are dark and the shadows are just more dark (black). I don't think there's anything that can be done about that and you should probably stick to light themes.

What if the shadow/blur used a color that contrasts the background?

I can also mention I feel quite disabled in front of Konsole's tab. It's physically impossible for me to tell which one is selected.

That's a fair point. The contrast between background and selected tabs isn't very noticeable in some cases. It would probably be a good idea to address that. I feel like I've seen tabs with underline focus decorations, but I can't figure out how to get those, which isn't a good sign.

The konsole tabs is a big one of my annoyances.

Yes, I kind of agree that the way the taskbar's visuals work don't make a lot of sense. Perhaps they should be more like the sidebar visuals I've been working on: https://i.imgur.com/N6FmN8K.png

Nice, one small change would be the "line" color which in your sidebar is already in the "active" state but on the taskbar it only happens when your pointer is hovering over the window in the taskbar.

That might be because the colors are dark and the shadows are just more dark (black). I don't think there's anything that can be done about that and you should probably stick to light themes.

What if the shadow/blur used a color that contrasts the background?

well, in order to have good contrast, the shadow would have to be a glow instead of a shadow. I think most users want to have a shadow and anyone who wants to change the shadow color can already do that.

On the topic of the dark theme: I think it currently has too much contrast. Most elements you see have a dark background with light text and light borders, which makes you (or in this case, me?) focus almost as much on the borders as their content. Making the borders more subdued, giving the tab area a lighter color to make up for it, making the buttons lighter than their borders, and using more pastel colors could be a start. Here's a quick edit of @ndavis 's screenshot/mockup as an example:

As an extra I also changed how the tabs look a bit, and removed the "General" header (It seemed redundant). I think the result looks easier on the eyes, even for a quick edit.

That might be because the colors are dark and the shadows are just more dark (black). I don't think there's anything that can be done about that and you should probably stick to light themes.

What if the shadow/blur used a color that contrasts the background?

well, in order to have good contrast, the shadow would have to be a glow instead of a shadow. I think most users want to have a shadow and anyone who wants to change the shadow color can already do that.

I don't know, glow effects are common to indicate what is active/requires attention in all kinds of interfaces. Shadows are a skeumorphic design and maybe we should try it and see how it looks? Where does the current setting live?

andreask removed a subscriber: andreask.Jul 28 2019, 8:53 PM
KonqiDragon added a subscriber: KonqiDragon.EditedJul 29 2019, 9:02 AM

On the topic of the dark theme: I think it currently has too much contrast. Most elements you see have a dark background with light text and light borders, which makes you (or in this case, me?) focus almost as much on the borders as their content. Making the borders more subdued, giving the tab area a lighter color to make up for it, making the buttons lighter than their borders, and using more pastel colors could be a start. Here's a quick edit of @ndavis 's screenshot/mockup as an example:

As an extra I also changed how the tabs look a bit, and removed the "General" header (It seemed redundant). I think the result looks easier on the eyes, even for a quick edit.

On the left is better with a black background..
On the right is better with a white background.
: |



But on the left is looks too flat.

On the topic of the dark theme: I think it currently has too much contrast. Most elements you see have a dark background with light text and light borders, which makes you (or in this case, me?) focus almost as much on the borders as their content. Making the borders more subdued, giving the tab area a lighter color to make up for it, making the buttons lighter than their borders, and using more pastel colors could be a start. Here's a quick edit of @ndavis 's screenshot/mockup as an example:

As an extra I also changed how the tabs look a bit, and removed the "General" header (It seemed redundant). I think the result looks easier on the eyes, even for a quick edit.

I don't use a dark theme because I don't like how it looks as much as the light theme, but I have to say that I find the proposed mockup here to be a huge improvement. I might actually use it from time to time if it looked like that.

ngraham moved this task from Backlog/Planned to Sent to dev on the VDG board.Aug 2 2019, 5:52 PM
ngraham moved this task from Backlog/Planned to Work in Progress on the Breeze board.
GB_2 added a subscriber: GB_2.Aug 4 2019, 1:22 PM


I think that making the gray here in sliders and scrollbars darker would also make Breeze look a lot better.

Here's another set of dark theme mockups (and some miscellaneous modifications to tabs, sidebars, title bars) :

And the original screenshots I used as a base, for comparison:

ndavis added a comment.EditedAug 9 2019, 11:02 PM

Here's another set of dark theme mockups (and some miscellaneous modifications to tabs, sidebars, title bars) :

And the original screenshots I used as a base, for comparison:

How/why did you pick those colors? Is there a method or formula that you follow?

How/why did you pick those colors? Is there a method or formula that you follow?

There's no strict formula; I just try to use pale/low-contrast colors when working with dark backgrounds, and high contrast only on lighter backgrounds. As for why, it's because vibrant colors on a dark background can hurt the eyes of a lot of people, mine included.

ndavis added a comment.EditedAug 10 2019, 1:50 AM

So what do you think about these highlight/selection/hover/focus colors? I chose them by taking Plasma Blue (#3daee9) from the KDE HIG and adjusting the brightness with HSLuv.org. The selection background color is 1/2 the brightness and the hover background is 2/3. I don't really know how to pick colors, so I'm taking a somewhat conservative approach where new colors are at least somewhat based on existing ones.

So what do you think about these highlight/selection/hover/focus colors? I chose them by taking Plasma Blue (#3daee9) from the KDE HIG and adjusting the brightness with HSLuv.org. The selection background color is 1/2 the brightness and the hover background is 2/3. I don't really know how to pick colors, so I'm taking a somewhat conservative approach where new colors are at least somewhat based on existing ones.
<image>

Personally, I'm not too keen on it. I don't mind the way buttons change when you highlight/select/hover them right now, and I try to avoid transparency as much as I can just so I can always find the right color in the palette. Also, I think @cblack had the right idea with colors, so you should take that as a base. Mine, on the other hand, were rough modifications that pretty much completely disregarded the HIG for the sake of seeing how things could be.

My biggest gripe with Breeze Dark in the end is just how it looks like an inverted Breeze Light, with all the elevation also inverted. I hope at least that can be addressed some day, as I think it's the main thing holding it back, and it doesn't look like it can be modified through Appearance > Colors. Here's one last example, taking again @ndavis 's screenshot, but this time done just by switching colors around (plus one new color for the button background).

Here's another set of dark theme mockups (and some miscellaneous modifications to tabs, sidebars, title bars) :

And the original screenshots I used as a base, for comparison:

This looks really good, the only gripe I have with it is the sidebar in the bottom right window is more visible with the current color to me.

So what do you think about these highlight/selection/hover/focus colors? I chose them by taking Plasma Blue (#3daee9) from the KDE HIG and adjusting the brightness with HSLuv.org. The selection background color is 1/2 the brightness and the hover background is 2/3. I don't really know how to pick colors, so I'm taking a somewhat conservative approach where new colors are at least somewhat based on existing ones.
<image>

Personally, I'm not too keen on it. I don't mind the way buttons change when you highlight/select/hover them right now, and I try to avoid transparency as much as I can just so I can always find the right color in the palette. Also, I think @cblack had the right idea with colors, so you should take that as a base. Mine, on the other hand, were rough modifications that pretty much completely disregarded the HIG for the sake of seeing how things could be.

My biggest gripe with Breeze Dark in the end is just how it looks like an inverted Breeze Light, with all the elevation also inverted. I hope at least that can be addressed some day, as I think it's the main thing holding it back, and it doesn't look like it can be modified through Appearance > Colors. Here's one last example, taking again @ndavis 's screenshot, but this time done just by switching colors around (plus one new color for the button background).

The first highlighted pushbutton (where the cursor is) is less visible in your version than noah's due to the contrast. And the radiobuttons has weird artifacts but maybe that's a compression thing.

The first highlighted pushbutton (where the cursor is) is less visible in your version than noah's due to the contrast.

Good contrast is what I've been focusing on the most with my work. https://webaim.org/articles/contrast/

I know that while the selection/hover background has a good contrast ratio with the text/icons (better than 4.5:1), the contrast ratio is definitely not good with the window background (less than 3:1), so I made sure to use outlines with lighter colors.

onvitaik added a comment.EditedAug 10 2019, 12:09 PM

The first highlighted pushbutton (where the cursor is) is less visible in your version than noah's due to the contrast. And the radiobuttons has weird artifacts but maybe that's a compression thing.

Visible as in readable, or discernible? I agree with the former as it has lower text/BG contrast, but not with the latter as the contrast between the button and the area around it went up. Plasma Blue (#3daee9), as it is, might be just too bright for a dark theme. A darker/paler blue (#428AAE) has a better contrast rating with both the background and the text (3.41 and 3.74 respectively, using https://jxnblk.github.io/colorable/demos/text). As for the artifacts, they are due to me quite literally selecting a color range and replacing it with another, so there was some collateral damage...

The first highlighted pushbutton (where the cursor is) is less visible in your version than noah's due to the contrast. And the radiobuttons has weird artifacts but maybe that's a compression thing.

Visible as in readable, or discernible? I agree with the former as it has lower text/BG contrast, but not with the latter as the contrast between the button and the area around it went up. Plasma Blue (#3daee9), as it is, might be just too bright for a dark theme. A darker/paler blue (#428AAE) has a better contrast rating with both the background and the text (3.41 and 3.74 respectively, using https://jxnblk.github.io/colorable/demos/text). As for the artifacts, they are due to me quite literally selecting a color range and replacing it with another, so there was some collateral damage...

Sorry, you're correct, I meant readable. I can discern that it's a button but I can't read at a glance what the text says. Using your link it says fail for the text in the button: https://jxnblk.github.io/colorable/demos/text/?background=%233daee9&foreground=%23DAFFFF

I'm partial to noah's approach of using a lighter outline to help with discernment.

Sorry, you're correct, I meant readable. I can discern that it's a button but I can't read at a glance what the text says. Using your link it says fail for the text in the button: https://jxnblk.github.io/colorable/demos/text/?background=%233daee9&foreground=%23DAFFFF

I'm partial to noah's approach of using a lighter outline to help with discernment.

I think you picked the wrong colors. I meant this: https://jxnblk.github.io/colorable/demos/text/?background=%23428AAE&foreground=%23fcfcfc which gives AA Large. Not the best, but not a fail, either.

Sorry, you're correct, I meant readable. I can discern that it's a button but I can't read at a glance what the text says. Using your link it says fail for the text in the button: https://jxnblk.github.io/colorable/demos/text/?background=%233daee9&foreground=%23DAFFFF

I'm partial to noah's approach of using a lighter outline to help with discernment.

I think you picked the wrong colors. I meant this: https://jxnblk.github.io/colorable/demos/text/?background=%23428AAE&foreground=%23fcfcfc which gives AA Large. Not the best, but not a fail, either.

Actually, it is a fail for typical usage. AA Large (3:1) means it meets the minimum requirement for large text (at least 18pt or 14pt bold) like page headers, not small text like lists and labels. The minimum for small text is AA Contrast (4.5:1).

mart added a subscriber: mart.Sep 4 2019, 1:25 PM

that's my take on dolphin, very few changes, mostly paying attenton to remove the frame in frame effects and have mostly single lines separators instead of all around frames


note there that some of those lines have been also purposed as focus indicator for the main icon view.. which is a thing that we may or may not want

Thanks Marco! That looks fantastic. Very much in the spirit of what we're going for here.

I'm not sure keeping the blue line focus indicators is actually necessary. Focus is easy to see when something is actually selected, with a blue selection background. In the case where nothing is selected but a view is focused, Dolphin's solution of showing a "virtual" focus line to show where focus would be makes sense to me.

Also note that we need to figure out our focused vs unfocused selection states. In the above mockup (and also the case in existing Dolphin) the Places Panel looks like it has focus because its list items have the active focus color for their background. But this is inaccurate because it is not focused. So it should have the an inactive-looking gray background color.

Elisa does this really well right now IMO (git master version) and could be used as an example

mart added a comment.Sep 4 2019, 1:36 PM

Thanks Marco! That looks fantastic. Very much in the spirit of what we're going for here.

I'm not sure keeping the blue line focus indicators is actually necessary. Focus is easy to see when something is actually selected, with a blue selection background. In the case

indeed.. on a related note not to have that focus thing makes the implementation from a mess to do to an *almost" straightforward one

michaldybczak added a comment.EditedSep 4 2019, 6:11 PM

I like the general direction where this is going. I'm using Kvantum theme on a daily basis which adds many of such effects anyway so I know from experience how well it works.

Here is the screenshot how Dolphin looks like in my setup:

I'm aware that the Breeze theme won't look exactly like that but I'm talking about details like:

  • the same coloring of titlebar (light theme) that melts with the app, I dislike the breeze theme because it's neither light or dark
  • lack of unnecessary separator lines that make the whole app look minimalistic, elegant and smooth
  • rounded titlebar corners
  • groupped, minimalistic icons on toolbar
  • lack of frame in frame effect (again, different modules melt with each other nicely)
  • thinner titlebar (breeze titlebar is just too thick and ugly, this is one of my biggest issues with it, almost all other titlebars are thinner then Breeze one, so the default is too thick, with too big buttons, the smaller size is too small, nothing in between in the right size)
  • many details that I don't even notice and you guys discuss it here

Remember, this isn't a mockup. I'm aware that this look isn't the goal, but I'm talking abut some details that are in common with the direction that this project is going and how it works well in practice, at least in my humble opinion.

Thanks, that is indeed not the goal, but I agree that there are elements that work quite well that we can poach--such as the lack of frames and the visually grouped toolbar buttons, especially for mutually-exclusive actions (AKA segmented controls; see https://bugs.kde.org/show_bug.cgi?id=384514). In terms of separation, we're going to use subtle single-pixel lines to separate major areas rather than going for a full "melted" look.

Kvantum theme allows for turning the grouping of taskbar icons on and off so this should be possible on Breeze as well. I found the grouping to be more aesthetically pleasing. I'm not sure if such grouping is already added to the Breeze theme thou. There are already separators in settings so we can define which icons go into which group so basically this is all well covered if the grouping is available.

I agree that for a default look, we need some subtle lines here and there, at least to point out the modules/elements of the UI. We still have different themes and Kvantum if we want alternatives and we shouldn't force a strongly defined (even fringe) theming onto everyone, so being conservative and keeping to well established and used standards must be a priority, despite personal preferences.

OK, enough of the general talk.

I think Breeze in general could really use some separators as a way to indicate one area is not attached to the other. Take Dolphin for example: The address area's background color is the same color as the sidebar's background, and with no visual separator, it looks like the two areas are directly linked. It looks strange.

Another suggestion is to make the toolbar/button bar the same color as the title bar. It looks more pleasant, in my opinion.

Here's a mockup. I also made the address bar and search bar occupy the same space.

I think Breeze in general could really use some separators as a way to indicate one area is not attached to the other. Take Dolphin for example: The address area's background color is the same color as the sidebar's background, and with no visual separator, it looks like the two areas are directly linked. It looks strange.

Yes, fixing that type of unnatural merging of dissimilar areas is an explicit goal of this effort.

Another suggestion is to make the toolbar/button bar the same color as the title bar. It looks more pleasant, in my opinion.

Yep, see T10201.

onvitaik added a comment.EditedSep 13 2019, 2:04 AM

Actually, it is a fail for typical usage. AA Large (3:1) means it meets the minimum requirement for large text (at least 18pt or 14pt bold) like page headers, not small text like lists and labels. The minimum for small text is AA Contrast (4.5:1).

That's true. But a lot of people, sites, and DEs are not too strict on themselves over the WCAG. Most of them settle for AA Large for contrast, with additional high contrast color schemes if the default is not enough.

After wondering about this a couple of times in the past month, I just ended up thinking that the Breeze palette also needs to get some focus. Plasma Blue did not seem to have been picked with good text contrast in mind - the same could hold true for other colors - with its really low color contrast (not even AA Large), and we can only dance around the issue for so long before we have too many cases where we attacked a symptom instead of the issue. We shouldn't be afraid of changing this if not doing so will do more harm than good in the long run. If anything, at the very least, Plasma Blue needs to be looked at. The palette provides other colors with better contrasts that could replace it but are never used anywhere, such as #3498db that is at least AA large.

ngraham updated the task description. (Show Details)Sep 15 2019, 5:21 PM

I was looking into Breeze panel & widget shadows. One complain that I sometimes hear, and I agree with it, is that the shadows are too dark and narrow, it almost looks like an outline. Other themes and OSs often use more sparse and lighter shadows. It's really important to be able to distinguish widgets and white windows, but such a strong shadow is not needed. I tweaked the SVG to show what I mean:

On the center, there is Breeze right now.
On the left there is shadow a bit more sparse and lighter.
On the right, there's a bit less sparse shadow with a bit more transparent background (personal favourite).

Top is widget to background image, bottom widget to white(-ish) window to show the contrast.

GB_2 added a comment.Fri, Oct 11, 3:22 PM

I was looking into Breeze panel & widget shadows. One complain that I sometimes hear, and I agree with it, is that the shadows are too dark and narrow, it almost looks like an outline. Other themes and OSs often use more sparse and lighter shadows. It's really important to be able to distinguish widgets and white windows, but such a strong shadow is not needed. I tweaked the SVG to show what I mean:

On the center, there is Breeze right now.
On the left there is shadow a bit more sparse and lighter.
On the right, there's a bit less sparse shadow with a bit more transparent background (personal favourite).

Top is widget to background image, bottom widget to white(-ish) window to show the contrast.

Love the right one too!

On the right, there's a bit less sparse shadow with a bit more transparent background (personal favourite).

Yeah, that is my opinion too. The shadow on the right is the best.

GB_2 added a comment.Sat, Oct 12, 7:41 AM

On the right, there's a bit less sparse shadow with a bit more transparent background (personal favourite).

Can you please make a patch?

Sure, but I wanted to try one last thing before. Using a bit that theme, I think that it's better that current shadow, but it still felt a bit wrong to me. I think that is due to the shadow moving together with elements and when using multiple elements close to each other, such as notifications.
I tried to see some other implementations, and I noticed that the shadow isn't usually very sparse, but it's also not radial, meaning that on the angles it's weaker than on the sides, and it does not go around to the angles with the same radius.


I tried to do something like this with Breeze shadows; I'm not sure on the outcome, do you have any opinions? (left: today, right: yesterday's proposal)

marcusgu removed a subscriber: marcusgu.Sat, Oct 12, 9:39 AM

Hmm... Maybe something in between? The left proposal is as if there was almost no shadow. It looks nice, very flat, but a bit overboard? It's not bad either. I mean, both look OK in their own way. It's probably a matter of personal taste on this point and I wouldn't be angry if one or the other was chosen.

mglb added a comment.Sat, Oct 12, 5:07 PM

Right one (larger shadow size). Plasma popups open above windows, yet they cast a lot smaller shadow than window shadow right now.

I tried to come up with a in between shadow, you can see that in D24593

michaldybczak added a comment.EditedSun, Oct 13, 6:57 PM

Can you make that shadow softer? The thinner it is, the harder it looks, thus less "shadowy" effect.

bodoeggert added a subscriber: bodoeggert.EditedThu, Oct 17, 8:56 AM

I do not like the shadow because the video in the next window will look broken,
but not having a shadow, I need window borders not in gray-on-gray. Currently the windows are not visually separated.

michaldybczak added a comment.EditedThu, Oct 17, 2:50 PM

I updated to Plasma 5.17 last night and the first thing I noticed were... huge, ugly shadows. This was a surprise. It's something different to see shadows in the screens and I did find them too big, but seeing them in a live system is something different.

Good shadows introduce subtle dimension and elegance and are basically not noticeable, but if they are in the face and act rather as oversized, ugly window borders like it is now - this is bad. It even looks like a step back so I welcome @niccolove's initiative to improve them even better.

However, shadows are a matter of taste, so maybe introducing an option to modify them would be a good idea? Latte-dock has an option to turn off panel shadow when a window is maximized, this is an awesome and very needed tweak because when we use upper panel, the shadow casting over the titlebar or tab bar or toolbar is just weird and out of place. In the past I had to modify the desktop theme to get rid of that shadow, now I don't have to. So maybe the extra tweak to breeze theme or maybe more general to kwin's desktop effects would improve the situation?

I updated to Plasma 5.17 last night and the first thing I noticed were... huge, ugly shadows. This was a surprise.

It's a surprise to me too because we didn't change the shadows at all in this release. :)

However, shadows are a matter of taste, so maybe introducing an option to modify them would be a good idea?

You can already modify the window shadows: System SettingsApplication StyleWindow DecorationsClick the pencil button in the Breeze theme item that appears on hoverShadows

I updated to Plasma 5.17 last night and the first thing I noticed were... huge, ugly shadows. This was a surprise.

It's a surprise to me too because we didn't change the shadows at all in this release. :)

Maybe some people did lose some settings; I read from another user who lost the border size (presumably not of breeze) by updating. Huge ugly shadows and no borders are the default.

Maybe some people did lose some settings; I read from another user who lost the border size (presumably not of breeze) by updating. Huge ugly shadows and no borders are the default.

Visible borders were turned off by default in this release, yes. But we didn't touch the shadows.

Anyway, this is material for a bug report at this point, so let's move it to a new ticket on bugs.kde.org. Thanks!

michaldybczak added a comment.EditedFri, Oct 18, 8:23 PM

Ah, right. Till now I didn't see much difference between the chosen theme and breeze. However, now the shadow is different and indeed Breeze has subtle, soft shadows so this is not a Breeze issue. Sorry, for the confusion.

To show the difference, here is the Breeze shadows (very nice, finally light titlebar and no borders - looks good):

And this is how it looks on my current aurorae theme:

I guess I can modify the theme myself, especially that it is already adjusted by me (when it comes to colors).