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 main window:

A Plasma settings window:

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

Details

Differential Revisions
D24706: [RFC] Change button style

Related Objects

StatusAssignedTask
OpenNone
Openngraham
Resolvedngraham
Openngraham
OpenNone
Openngraham
Openngraham
Openmglb
OpenNone
Openndavis
Openndavis
OpenNone
Openndavis
Openngraham
Openngraham
OpenNone
Resolvedngraham
Openniccolove
OpenNone
Openngraham
Openngraham
OpenNone
OpenNone
OpenNone
Openhein
OpenNone
Openngraham
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
Openndavis
Openngraham
There are a very large number of changes, so older changes are hidden. Show Older Changes

@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
This comment was removed by KonqiDragon.

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.Oct 11 2019, 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.Oct 12 2019, 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.Oct 12 2019, 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.Oct 12 2019, 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.EditedOct 13 2019, 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.EditedOct 17 2019, 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.EditedOct 17 2019, 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.EditedOct 18 2019, 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).

ngraham updated the task description. (Show Details)Oct 29 2019, 9:00 PM
ndavis added a comment.EditedNov 11 2019, 8:51 AM

I think I need to write down some of my ideas in a public place even if they aren't well organized or end up not being very good.

Hover Colors

  1. Stop using a dedicated color from the colorscheme. Instead, the hover color should depend on the color it's replacing. It should increase the contrast between the foreground and background.
    • Examples
      • If the button background color is light and the button text color is dark, increase the lightness of the button background color on hover
      • If the button background color is dark and the button text color is light, decrease the lightness of the button background color on hover
  2. The purpose of hover is to show what can be interacted with and what you will interact with if you press a mouse button

Focus & Selection Colors

  1. Why do we have a FocusColor for each ColorSet (View, Window, Button, Selection, Tooltip, Complementary) and why does QPalette::Highlight only map to Selection Background? I can understand why Complementary might have and extra version of it, but it's just confusing to have to pick where the (View|Window|Button|Selection|Tooltip) FocusColor should be used.
    • Plasmashell tends to prefer using Button FocusColor and QPalette::Highlight
    • The Breeze QStyle uses only View FocusColor and QPalette::Highlight
    • QPalette::Highlight is used basically interchangeably with FocusColor throughout Plasma and Breeze (probably any custom widget too), but is technically not the same. This causes consistency problems when the Selection Background color is different from the FocusColor.
    • Maybe we should just use Selection ColorSet for everything related to highlights and stop using the FocusColor for other ColorSets.
  2. Have a Focus/Selection decoration foreground color and Focus/Selection decoration background color instead of Focus colors and a Selection Background color (Selection Text is not related to this)
    • Focus/Selection decoration foreground color should be #3daee9
    • Focus/Selection decoration background color should be either (only pick one) the original window/view/button BG, but 33% mixed with the FG or 40% tinted with the FG color
      • equivalent to KColorUtils::mix(backgroundColor, focusColor, 0.33) or KColorUtils::tint(backgroundColor, focusColor, 0.4)
      • The 33% mix is just like using 33% opacity on the Focus/Selection FG color, but is better for floating buttons than actual semi-transparency because the resulting color is solid.
      • The 40% tint may be prettier than mixing with some color combinations because it's better at preserving the hue and chroma of the Focus/Selection color. It also works well for floating buttons.

Alternate Background Colors

  1. These aren't used often and don't need to be, but we could use them more to make Breeze more customizeable.
  2. View, Window and Selection AlternateBackground should probably be used in the same way (for alternating rows)
  3. Sunken button color should be Button AlternateBackground
  4. No idea what Tooltip Alt BG should be used for, but it doesn't need to be used.

Separator/Frame Colors

  1. These should be customizable to at least some degree
    • Perhaps a new color should be introduced to KColorScheme?
  2. Perhaps we should have 2 types of Separator/Frame colors?
    • Hard: just like the current separators/frames
    • Soft: same base color as hard, but mixed with the background color a bit to make it look fainter
      • For non-separator things that can't be interacted with and don't need a lot of visual priority, like group boxes
      • Maybe consider removing any frames that would use the Soft type? Too much visual noise from lots of frames is a common complaint. It's particularly bad in GUIs that haven't been changed much for a long time.
  3. Consider using very thin shadows (basically dark gray lines) instead of separators in some cases where there is a difference in hierarchy between 2 adjacent parts of the UI.
    • Example: after T10201 is implemented, we can put one of these dark lines below the toolbar/above the main window area

Titlebar Colors

  • I think they really ought to have their own ColorSet in KColorScheme. This way, we could have a complete set of colors for CSD headerbars.

Ooh, interesting thoughts. Let's see:

Hover Colors

This could be fairly easy to implement, depending on how Breeze currently paints the color. For my theme I'm painting the titlebar's font in a dynamic way like so:

const QRgb brightFont = 0xFFFFFFFF;
QColor color = ( this->titleBarColor() );
int y = 0.2126*color.red()+0.7152*color.green()+0.0722*color.blue();
QColor newFont ( forceBrightFonts() ? brightFont : y > 128 ? color.lighter(40) : brightFont );

It's taking the color of the titlebar and calculating a lightness value (0-255) with y. Afterwards a check for the value is done and color adjusted accordingly. On a button it could look similar (pseudocode):

QColor color = ( this->buttonBackgroundColor() );
int y = 0.2126*color.red()+0.7152*color.green()+0.0722*color.blue();
QColor hoverColor ( y > 128 ? color.lighter(40) : color.lighter(180) );

That way the color adjusts accordingly to the color scheme's base color.

Frame Colors

Could be done in the same way. Also for my theme I'm drawing the titlebar seperator with a similar check and use a darkened variant of whatever the colorscheme sets the titlebar color to be.

Ooh, interesting thoughts. Let's see:

Hover Colors

This could be fairly easy to implement, depending on how Breeze currently paints the color. For my theme I'm painting the titlebar's font in a dynamic way like so:

const QRgb brightFont = 0xFFFFFFFF;
QColor color = ( this->titleBarColor() );
int y = 0.2126*color.red()+0.7152*color.green()+0.0722*color.blue();
QColor newFont ( forceBrightFonts() ? brightFont : y > 128 ? color.lighter(40) : brightFont );

It's taking the color of the titlebar and calculating a lightness value (0-255) with y. Afterwards a check for the value is done and color adjusted accordingly. On a button it could look similar (pseudocode):

QColor color = ( this->buttonBackgroundColor() );
int y = 0.2126*color.red()+0.7152*color.green()+0.0722*color.blue();
QColor hoverColor ( y > 128 ? color.lighter(40) : color.lighter(180) );

That way the color adjusts accordingly to the color scheme's base color.

I did it by comparing the lightness of the button text to the button background. This way the text is kept readable, even with some odd choices from the user, like a dark background and even darker text.

Frame Colors

Could be done in the same way. Also for my theme I'm drawing the titlebar seperator with a similar check and use a darkened variant of whatever the colorscheme sets the titlebar color to be.

I don't think separators and frames need to have anything fancy. A pre-defined color is good enough and makes it possible for users to customize it.

The window decorations in the two images are not the same.

The window decorations in the two images are not the same.

It's a mock-up. ;)

The window decorations in the two images are not the same.

It's a mock-up. ;)

Yes, I'm aware of that. But in a task about visual evolution, it is kind of important, that things are consistent, otherwise it's hard to tell what we are talking about.

Hello friends

I really like this attempt to improve the breeze theme!
but I think it can be improved more by using more bold/thicker scrollbar in the KDE environment and GTK theme also. TBH if we're going for a consistent look it looks nicer to not have borders around the scrollbars also like the below screens

An option to shrink the size of the scrollbar is also welcomed, to save some space specially in smaller screens

voidfragment added a subscriber: voidfragment.EditedSun, Jan 5, 5:47 AM

Please, make frames at all buttons. So, current Breeze checkboxes are classy, no need to change them

Please, make frames at all buttons

I hear this request a lot. I think it's something we might want to investigate, if we can make them look lightweight enough. The reason why ToolButtons generally don't have outlines is because they're designed to be used in long rows on toolbars where it's thought that giving them frames makes them look visually noisy, "heavy," and overwhelming.

Then again Apple has standardized on buttonlike toolbar buttons for ages and I think it looks fine:

Being able to do this would be helped substantially by T11665: Make adjacent mutually exclusive ToolButtons look like segmented controls.

if we can make them look lightweight enough

I absolutely agree with you.

T11665: Make adjacent mutually exclusive ToolButtons look like segmented controls.

This variant is really, really nice!

kkoma added a subscriber: kkoma.Fri, Jan 10, 2:10 PM
gikari removed a subscriber: gikari.Fri, Jan 10, 5:17 PM