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

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


Note that as a part of this effort, I have explicitly not added as a goal rounding the bottom corners of the windows when No Borders is in use. This idea is controversial and has the slight, but real potential to interfere with applications that put interactive elements in the bottom corners. It needs more discussion if we want to do it. In the meantime, people who want to accomplish this can use https://github.com/alex47/KDE-Rounded-Corners.

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
Resolvedngraham
Openngraham
Openngraham
OpenNone
OpenNone
OpenNone
Openhein
OpenNone
Openngraham
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
Wontfixndavis
Openngraham
Openngraham
OpenNone
OpenNone
There are a very large number of changes, so older changes are hidden. Show Older Changes
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.

joeyelo added a subscriber: joeyelo.Jan 4 2020, 5:31 AM

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.EditedJan 5 2020, 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.Jan 10 2020, 2:10 PM
gikari removed a subscriber: gikari.Jan 10 2020, 5:17 PM
ngraham updated the task description. (Show Details)Feb 20 2020, 5:21 PM
mart added a comment.Feb 20 2020, 5:34 PM

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

i really don't like the look of that toolbar at all :/

mart added a comment.Feb 20 2020, 5:35 PM

i would really hate all frames on toolbuttons like that

I'm also against framing all buttons in the toolbar. It just does not feel very aesthetic in Breeze to me.

jalzen added a subscriber: jalzen.EditedSun, Mar 8, 10:29 AM

The mock-ups in the task description looks perfect to me. It is clean and modern, especially with the Dolphin picture. I especially like that the menu bar is gone 👍


This design is amazing! Would it be possible to create something like this?


This design is amazing! Would it be possible to create something like this?

That's just a clone of macOS Finder. Third-party theming is of course still fully supported, but that's not the direction we're going in for this task.


This design is amazing! Would it be possible to create something like this?

That's just a clone of macOS Finder. Third-party theming is of course still fully supported, but that's not the direction we're going in for this task.

It is a screenshot from this video - If Apple Created Windows 10 (Concept by Avdan), video looks very kool!
He did also some other concepts, maybe we can get some good ideas from his concepts?
Introducing macOS 11 Ventura (Concept by Avdan)
The New Windows 11 Concept by Avdan

I think the gradient in the dark theme is too heavy, and kinda contrasts with the content of the window. Nowhere else but the window border (at least in the dark theme) has gradients, and the current gradient isn't subtle at all. Maybe tone it down a bit?

Also it might be interesting to change the defaults for menu transparency, as to match the panel transparency:

Also it might be interesting to change the defaults for menu transparency, as to match the panel transparency:

+1 from me

If we want to do that, we should consider applying the "Background contrast" KWin effect to menus as well. I notice that right now it does not affect transparent menus, which causes issues such as https://bugs.kde.org/show_bug.cgi?id=397851.

Also we would want to fix https://bugs.kde.org/show_bug.cgi?id=399680 (see the number of duplicates!).

If we make those technical fixes, I have no objections!

It looks really nice but that will make GTK apps a bit inconsistent :c

abstractdevelop added a comment.EditedThu, Mar 26, 9:31 PM

Hm yes. But once the breeze evolution is done we will have to push a lot of things into Breeze GTK, won't we?

It looks really nice but that will make GTK apps a bit inconsistent :c

Hm yes. But once the breeze evolution is done we will have to push a lot of things into Breeze GTK, won't we?

Would it be technically possible to render GTK apps with KWin effects? Blur and Contrast for example. If somehow GTK apps could be rendered with effects, that would allow more visual consistency without the use of ugly scripts and packages that force GTK apps to drop their client-side decorations and render KWin window borders and titlebars. Also KDE would have finer control over the window buttons of GTK apps, and some apps would look totally amazing with a touch of blur and a semi-transparent sidebar. Browsers would look better too.

I don't think that consistency with GTK application should prevent us to make something pretty and consistent throughout KDE applications :-)

On a different note, how do you feel about increasing the radius of the titlebar? I think it might make the window look prettier.

I would like to do that--though maybe just a bit. However what I really want is rounded bottom corners when there are no borders, which would bring it into consistency with the topcorners. This would require having the window manager clip a few pixels from the window's content, which I know is heresy and sacrilege to some, but I genuinely don't see that it's actually a problem at all.

ngraham updated the task description. (Show Details)Fri, Mar 27, 4:59 PM
kkoma added a comment.Fri, Mar 27, 6:00 PM

I would like to do that--though maybe just a bit. However what I really want is rounded bottom corners when there are no borders, which would bring it into consistency with the topcorners. This would require having the window manager clip a few pixels from the window's content, which I know is heresy and sacrilege to some, but I genuinely don't see that it's actually a problem at all.

I couldn't agree more. Most apps don't have anything that close to the corner anyway, and even if an UI element extends that far into the corner, it is usually way bigger, like a sidebar element or a button. Those would not cause any problem. The users wouldn't even notice. And apps that have really small elements in the corners, or corner actions, are so badly designed that people won't use them anyway. Elements of a size where this would be a problem generally stab Fitt's Law in the guts, and visual consistency and appearance should not be sacrificed to make those work.
Alternatively, the default border size could be a bit bigger, allowing for more corner rounding without cutting into window content. In this case though, sidebar entries (like in Discover) should be rounded too, as sharp edges a few pixels away from the edge look odd. This somewhat contradicts the directive to use 1px lines to separate parts of the UI instead of frames or just no separation, but it is worth taking into consideration.
So ultimately the solution is to clip a few pixels, and anyone who is against that solution should present a valid example of this being an usability problem, apart from them (a rare minority of 1-2 people) being used to playing tickle with windows and clicking everything in the bottom left or bottom right 2px by 2px area, or clicking on things in a scrollable view that barely show a few pixels on the bottom of the window.

On the matter of scrolling: Would it be posible to scroll app views in a way that moving the scroll wheel one click up/down moves one row of controls/items up/down, as in makeing sure to fit the entirety of the next row of the layout on the screen? With a smooth animation (and a toggleable setting of course) this would make Plasma and KDE in general feel more modern, snappier and nicer. This smooth scrolling could be implemented for touchpads and touchscreens too.

Yes, those rounded corners at the bottom are really nice! +1 on doing this. ;)

jnovo added a subscriber: jnovo.Sat, Mar 28, 12:02 PM
paulm added a subscriber: paulm.Sat, Mar 28, 8:09 PM

On a different note, how do you feel about increasing the radius of the titlebar? I think it might make the window look prettier.

I think there is nothing wrong with the way it is and increasing the rounding makes the interface look less professional and more toyish (and like GNOME). The corners are useful for resizing, and changing this makes the resize corner potentially closer to other controls; occasionally there may be content in the corner too.

occasionally there may be content in the corner too.

What content? Could you please give an example? As long as windows have reasonable margins regardless of KWin border sizes, rounded corners should not be a problem. It would not be 100px radiuses, only a few, no content would ever notice.

Fullscreen or snapped windows though, they should be un-rounded to avoid weird peep-holes at the corners of maximized or touching windows.

Maybe the rounding of corners (top and bottom) could be optional?

If you round the corners, make sure that by moving the mouse into a corner of the screen, you grab the window. Otherwise I'll be cursing again and search for a way to disable that. Just like I did with the current version. (The preview of the selected theme shows round corners, but my windows have rectangular corners and I have no clue what I did back then).

An example of content-in-a-corner might be a VM that only opens a menu if the mouse is exactly at that one pixel in the bottom right corner.

When windows are tiled or maximized, the rounding is turned off to facilitate those exact situations. This is something we already have today, and I don't think there's any desire to change that. :)