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
  • 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: 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
  • Separate views from one another with with single-pixel lines rather than putting everything in a frame: T11661
  • 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:

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
Resolvedjriddell
Openngraham
Resolvedngraham
Openngraham
OpenNone
Openngraham
Openngraham
Openndavis
OpenNone
Openndavis
Openndavis
OpenNone
Openndavis
Openngraham
Openngraham
OpenNone
Resolvedngraham
Openniccolove
Resolvedngraham
Openngraham
Openngraham
OpenNone
OpenNone
Resolvedniccolove
Resolvedngraham
Openhein
OpenNone
Openngraham
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
Opensharvey
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
Wontfixndavis
Openngraham
Openngraham
OpenNone
OpenNone
OpenNone
Opencblack
OpenNone
There are a very large number of changes, so older changes are hidden. Show Older Changes
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.EditedMar 8 2020, 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.EditedMar 26 2020, 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)Mar 27 2020, 4:59 PM
kkoma added a comment.Mar 27 2020, 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.Mar 28 2020, 12:02 PM
paulm added a subscriber: paulm.Mar 28 2020, 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. :)

tvshtr added a subscriber: tvshtr.Apr 16 2020, 2:30 PM
This comment was removed by tvshtr.

Konsole is a frequently used and core KDE application. That can have content (part of the first letter) in the corner depending on the window size.

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.

Please tone it down a bit. The style should never hinder the functionality of applications. Also if you feel an app is badly designed work with the developers to improve them. Not everyone is a designer and most developers love getting feedback/recommendations for user interface. The solution is not that VDG should ignore such programs but work on improving them.

kkoma added a comment.Apr 16 2020, 6:33 PM

Konsole is a frequently used and core KDE application. That can have content (part of the first letter) in the corner depending on the window size.

Well that is a valid argument, but with readable font-sizes, the corner wouldn't take away enough pixels to cause a problem, at least as I see it.

ndavis added a comment.EditedApr 16 2020, 7:52 PM

This is what Konsole would look like with rounded corners:
With powerline style prompt:


With text on the last line:

I'm using 0px line spacing and 0px terminal content margins

i.e. not a problem at all. :)

kkoma added a comment.Apr 16 2020, 8:45 PM

And the result would be similar with other apps. The only edge-case left now is a VM with corner interaction (like Plasma's Screen Edges) running in windowed mode.
I guess the best practice would be to add a setting to enable round corners, maybe even tweak the radius, in the System Settings > Application Appearance > Window Decoration page, maybe as a 'Tweaks' tab (that would also display the settings currently accessed by clicking the pencil icon in the grid view), or include it in the settings window of the decoration, or just a slider at the bottom since there is already border size there.
And add a setting for this in the Window Rule settings window, so it can be turned on/off for specific windows.
Common VM apps could be added to the blacklist by default.
Tiled and maximized windows should have no round corners. Or maybe include a setting for that too. (There could be a button in the bottom bar of the Window Decorations page, named "Corner preferences" or "Corner radius" which would show a popup or an inline expansion overlay to configure the radius of corners, the tiling/maximized behaviour and maybe a link to window rules, something along these lines.)
Also care must be taken to exclude any window that Plasma might show (popups, menus, the Leave screen, Application Dashboard, panels, Latte panels), which aren't real windows.

Another thing to consider is that in order for this to properly work, nothing should be drawn in those pixels that the rounding takes away. Nothing. Not even a blur effect. They should be as crisp as the straight part of the window edge. Only the window shadow could be allowed. Speaking of which, the shadows also have to be adjusted to accommodate the roundness and not feel weird. These are just details though.

ndavis added a comment.EditedApr 17 2020, 12:02 AM

I don't think window shadows would have to be adjusted at all for the roundness.

vjack added a subscriber: vjack.Apr 19 2020, 9:22 PM

https://github.com/alex47/KDE-Rounded-Corners does have issues on Wayland with multi monitor so be careful before this gets merged into kwin (which I hope for eventually). Screenshot is Breeze not an aurorae deco.

joricke removed a subscriber: joricke.Apr 20 2020, 3:34 PM

Another thing to consider is that in order for this to properly work, nothing should be drawn in those pixels that the rounding takes away. Nothing. Not even a blur effect. They should be as crisp as the straight part of the window edge. Only the window shadow could be allowed.

A lot of themes are affected by this issue, where the round corners look strange when the blur effect is enabled. Even if Breeze is not going to get round corner support, this would be great to have for other themes to make use of.

I've had issues with the rounded corners on X11 as well. Certain windows don't appear to have transparent corners. The background of the rounded corners ends up being black or white.

I believe the konsole was one area where this happened (not on my home machine ATM so I can't check). Konsole of course, has other visual glitches (maybe related to NVIDIA?)

I don't know where to put this, so
I'd propose to keep the panel transparent but make the widget opaque. Here's how this would look with some different active applet designs:


The first and the last one are IMO prettier but technically very problematic to do, but he middle one should be fairly easy. +1/-1? Should I make a patch for it? Any alternative designs that don't require additional elements that link to the widget?

onvitaik added a comment.EditedJun 24 2020, 6:11 PM

+1/-1? Should I make a patch for it? Any alternative designs that don't require additional elements that link to the widget?

+1. I really like that last one, while the first one looks strange. The middle one is fine, too, though I don't think the blue highlight bar shows the widget is connected to the panel quite as well as the arrow.

ngraham updated the task description. (Show Details)Jun 25 2020, 3:22 PM
ngraham updated the task description. (Show Details)Jun 25 2020, 4:40 PM


The first and the last one are IMO prettier but technically very problematic to do, but he middle one should be fairly easy. +1/-1? Should I make a patch for it?

I can't quite remember if that was discussed before but I think we want all highlight effects on the panel to be the same in the long run. That would really help with the overall user experience imo. I don't think the first one would really work for task managers or at least some design work is necessary to make it work. Aside from the panel highlight aspect I don't really have an opinion on this but I encourage you to make a patch if you think it is an improvement. :^)

baran added a subscriber: baran.Jun 26 2020, 11:18 AM

I am not sure if this is the correct place to ask this question. Sorry, if it is not. This is unrelated to the theme.

I am foreign to KDE and Plasma but I noticed that in the Plasma settings mockup, the title "Icons" is separate from the content. Why this is the case? Wouldn't it be better if the title and the settings were somehow more together. For instance, the title would be centered too. I don't know but if every other program uses left aligned titles, maybe, this left aligned way is more consistent.

I am not sure if this is the correct place to ask this question. Sorry, if it is not. This is unrelated to the theme.

I am foreign to KDE and Plasma but I noticed that in the Plasma settings mockup, the title "Icons" is separate from the content. Why this is the case? Wouldn't it be better if the title and the settings were somehow more together. For instance, the title would be centered too. I don't know but if every other program uses left aligned titles, maybe, this left aligned way is more consistent.

This mockup doesn't really reflect our plans.

ndavis updated the task description. (Show Details)Jun 26 2020, 2:26 PM