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. - Under discussion: T10201
  • The Tools Area's background becomes lighter or desaturated for inactive windows: T10201
  • Window shadows become slightly smaller for inactive windows: https://bugs.kde.org/show_bug.cgi?id=393238
  • Make settings windows' left category sidebars have a white background and a single-pixel separator between them and the content view: D20908
  • Move away from putting the main content view in a frame, and instead frame it with what surrounds it (window edges, Tools Area, left sidebar, etc)
  • Use all colorful icons for settings windows' categories - In progress: T10165
  • Use colorful icons for small-sized places, devices, and mimetype icons - under discussion: T10870
  • Make the checkbox's checked state look like a checkmark: T10997

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

Here are some crude mockups of how it would look:

Dolphin window:

Inactive Dolphin window;

A Plasma settings window:

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

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes

Can we enlarge the window decorator buttons? In particular, the circle to close a window requires a user a decent amount of precision since it's pretty tiny and doesn't reach the corner. Look at Windows' close button for instance.

The click area extends beyond just the circle, so there's no actual usability issue here.

where can I get this nice looking checkboxes in svg?

Sorry, it was just a crude GIMP mockup. :)

Would it be possible in this evolution to explore more streamlined spin boxes? I have always felt, our current version mixes the control with the content and it would probably be cooler to have them look separate. Maybe more like this:

https://images.app.goo.gl/TmNs1cWBrH2oyiRc7

Or this

https://images.app.goo.gl/PLed1isQZcSMwGiE9

I actually think the macOS spinbox is really ugly--much worse than our status quo. If we're gonna fiddle with the spinbox, I'd actually like the controls to be more obvious, so they're more cliciable and actually usable for touch. See T9460.

In T10891#185635, @mglb wrote:

Checkboxes look nice, but they don't match other elements - everything else uses basic shapes, and the check mark on OK button is quite different.

Maybe something like this?

So much better than my version!

From what I've seen, your programming skills as well as sense of visual design are quite impressive. Would you be interested in working on a Breeze patch to implement this new style?

Looks like folks are excited about this: https://www.reddit.com/r/kde/comments/bqnorv/with_the_right_layout_kde_apps_can_look_really/

Check out one person's tweaked Dolphin window:

Looks pretty similar to what this task aims to accomplish, I'd say.

In T10891#185635, @mglb wrote:

Checkboxes look nice, but they don't match other elements - everything else uses basic shapes, and the check mark on OK button is quite different.

Maybe something like this?

I need them for something else not breeze related. In svg

mglb added a comment.May 21 2019, 11:58 PM

Would it be possible in this evolution to explore more streamlined spin boxes? I have always felt, our current version mixes the control with the content and it would probably be cooler to have them look separate. Maybe more like this:

https://images.app.goo.gl/TmNs1cWBrH2oyiRc7

Or this

https://images.app.goo.gl/PLed1isQZcSMwGiE9

To maintain consistent look, it would be nice to also change arrow in editable combo box and maybe clear button in line edit.

In T10891#185635, @mglb wrote:

Checkboxes look nice, but they don't match other elements - everything else uses basic shapes, and the check mark on OK button is quite different.

Maybe something like this?

So much better than my version!

From what I've seen, your programming skills as well as sense of visual design are quite impressive. Would you be interested in working on a Breeze patch to implement this new style?

Yes, should I make a task for it?

Go right ahead!

onvitaik added a subscriber: onvitaik.EditedMay 24 2019, 2:07 AM

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


(Text is a bit cut off at the end. It meant to say "as changes would be applied immediately")

Most of the reasons for the changes are to the side of the mockup. I wanted to include some other comments, like how child areas need to look more distinct from their parents (It was one of the linked reddit post's complaints: https://i.imgur.com/sJ0zE6b.png), but for now...

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

{F6844666}

(Text is a bit cut off at the end. It meant to say "as changes would be applied immediately")

Most of the reasons for the changes are to the side of the mockup. I wanted to include some other comments, like how child areas need to look more distinct from their parents (It was one of the linked reddit post's complaints: https://i.imgur.com/sJ0zE6b.png), but for now...

I really like how streamlined and focus the UI is. No space seems to be wasted. The header being enclosed with a divider line might be a challenge, but seems to work. The toolbar at the top might be a challenge visually, but we can work on it. Good start.

{F6844666}

Neato! Things I like about this:

  • Toolbar on top of page that has the title on it, instead of the title just floating in the top-left corner of the page
  • Title is centered rather than left-aligned
  • Use of lighter color on interactive UI controls to distinguish them from the page background
  • Use of buttons with frames instead of frameless toolbuttons
  • Visual changes to comboboxes, sliders, and checkboxes
  • Removal of OK/Apply/etc buttons, which implies the use of the "instant apply" paradigm throughout the settings

Things I don't like:

  • Drop shadows added to UI controls; seems unnecessary
  • Things seem more square; I think the current level of roundedness is fine
  • Changes to sidebar's header; now feels crowded and weird

Nice to see it's well-received!

Things I don't like:

  • Drop shadows added to UI controls; seems unnecessary
  • Things seem more square; I think the current level of roundedness is fine
  • Changes to sidebar's header; now feels crowded and weird

Do you mean the buttons specifically? Them looking more square is probably because they're lighter and shorter, as I didn't touch their roundness directly. I did forget to change the drop shadow of the slider pick and the checkboxes, though, and they ended up looking smoother than the rest. They were all meant to combine the shadows with the border like I did for the buttons: left and right sides being lighter than the right and bottom ones to give a small impression of depth. Here are some button variants (The CSS doesn't produce quite the same results):

The changes for the sidebar header weren't meant to crowd it; They were meant to have something the user always know it's there, no matter the page. Right now, once you select something (Workspace Theme, Colors, Fonts...) the search bar and hamburger menu disappear and are replaced with the title and the return button. I don't think you need to hide both of them. Here's another, less crowded mockup:

mglb added a comment.May 25 2019, 1:35 AM

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

{F6844666}

(Text is a bit cut off at the end. It meant to say "as changes would be applied immediately")

Most of the reasons for the changes are to the side of the mockup. I wanted to include some other comments, like how child areas need to look more distinct from their parents (It was one of the linked reddit post's complaints: https://i.imgur.com/sJ0zE6b.png), but for now...

Centered title is awesome!

However, I see two problems:

  • Non-editable combo boxes look like editable combo boxes. It is also possible to confuse buttons and line edits with centered text. The latter is really problematic - line edit can be clicked without any consequences, buttons can't.
  • Instantly applied settings:
    • Changing some settings is slow. Some have inconvenient side effects not easy to fix without hacks. E.g. window flags change causes the window to be hidden and shown, what resets some WM properties (desktop, minimized state under X with thumbnails turned on, etc).
    • Would need a lot of work - all applications would need to be adjusted for it. While not really a problem in itself, it would need its own task :)
    • There should be something to undo the changes.

More overall ideas:

  • Widgets heights should be somehow unified. Here's Konsole's profile editor without custom code which makes heights equal:



    Another option would be to make custom layout, so this is not something that must be solved in the style.
  • Buttons related to a field could be joined with the field, like arrow button in combo box. Could be done with a separator like in @onvitaik's combo and spin boxes. This would make showing on demand possible (like clear in line edit currently).

In T10891#186101, @mglb wrote:

Centered title is awesome!

However, I see two problems:

  • Non-editable combo boxes look like editable combo boxes. It is also possible to confuse buttons and line edits with centered text. The latter is really problematic - line edit can be clicked without any consequences, buttons can't.
  • Instantly applied settings:
    • Changing some settings is slow. Some have inconvenient side effects not easy to fix without hacks. E.g. window flags change causes the window to be hidden and shown, what resets some WM properties (desktop, minimized state under X with thumbnails turned on, etc).
    • Would need a lot of work - all applications would need to be adjusted for it. While not really a problem in itself, it would need its own task :)
    • There should be something to undo the changes.

Yeah, editable combo boxes didn't cross my mind. I think swapping the button look for the line edit look would be enough, as buttons and line edits would differ in how they're displayed. For example, If buttons look like concave, then line edits would look convex.

As for buttons and line edits with centered text, there could be something inside the latter that shows they're not buttons, like a button to clear the text. OSX shows it differently, by putting small lines on the sides of the line edits, with no clear text button.

Taking a page from other OSes/DEs once again, settings changes on Windows, OSX, and Gnome are also instantly applied instantly. Well, not instantly as there might be a delay, but it works well enough that they decided they could safely take out those buttons, and through using all of them for a decent amount of time, I haven't really missed them. Offering a way to undo a change should be limited to settings that can break the way you use the entire DE, like changing resolutions. On the other hand, I think a "reset to defaults" button would be nice. But I digress... This is indeed something that would need its own task.

In T10891#186101, @mglb wrote:

More overall ideas:

  • Widgets heights should be somehow unified. Here's Konsole's profile editor without custom code which makes heights equal:
{F6847130, size=full}

Though it's not a unification, changing the button size like I proposed could alleviate this issue, since buttons/line edits/etc are the ones that take the most vertical space compared to all other widgets. AFAIK, that's something even other DEs haven't bothered to deal with that issue much (At least from looking at windows, OSX, and Gnome).

My crude solution to those mismatching heights would be to avoid placing widgets with different heights on the same line unless there's no other way. For example, I'd move the "Fixed size" option to the last spot, and place the spin box directly under it.

In T10891#186101, @mglb wrote:

More overall ideas:

  • Widgets heights should be somehow unified. Here's Konsole's profile editor without custom code which makes heights equal:

What about adapting the spacing of the view to accommodate the inline widget taking the most height? So in the example all of them would be spaced by 29px. This can work with unification, so it can adapt even to custom widgets. I assume the custom code you're referring to achieves something like this, maybe that should be generalized.

mglb added a comment.May 26 2019, 8:37 AM

As for buttons and line edits with centered text, there could be something inside the latter that shows they're not buttons, like a button to clear the text. OSX shows it differently, by putting small lines on the sides of the line edits, with no clear text button.

I just realized line edit and button in macOS are both white and have similar size :) But they have different corner radius and are sunken/raised, respectively. I wonder how would it look in KDE.

Though it's not a unification, changing the button size like I proposed could alleviate this issue, since buttons/line edits/etc are the ones that take the most vertical space compared to all other widgets.

I guess buttons and inputs will never be as small as checkboxes (even on the screenshot there is 26px for inputs and 16px+shadow for checkboxes), but checkbox/radio button can have larger margins.

My crude solution to those mismatching heights would be to avoid placing widgets with different heights on the same line unless there's no other way. For example, I'd move the "Fixed size" option to the last spot, and place the spin box directly under it.

It is default option, hence it is first. Separate line is best when possible, but sometimes it looks weird (e.g. 50px wide color selector button)

In T10891#186101, @mglb wrote:

More overall ideas:

  • Widgets heights should be somehow unified. Here's Konsole's profile editor without custom code which makes heights equal:

What about adapting the spacing of the view to accommodate the inline widget taking the most height? So in the example all of them would be spaced by 29px. This can work with unification, so it can adapt even to custom widgets. I assume the custom code you're referring to achieves something like this, maybe that should be generalized.

If you mean automatically adjusting rows with checkboxes and radio buttons, this could be nice. However, I see some possible technical problems (sizeHint() races as the size depends on other elements, etc).

Would it be "too" crazy to want the checkboxes background to be white? I think they bring nice contrast to the page and sets the checkbox apart.

I second to the white background on checkboxes. The white background suggests it's clickable, active. Gray or the same background as the other window suggests as if it was inactive for some reason.

In T10891#186175, @mglb wrote:

If you mean automatically adjusting rows with checkboxes and radio buttons, this could be nice. However, I see some possible technical problems (sizeHint() races as the size depends on other elements, etc).

A custom Qt layout similar to this one could work.

mglb updated the task description. (Show Details)May 27 2019, 8:09 PM

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

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


Or Krita?

What about changing a thing almost +80% of people are used to? (Windows/Linux)
Think about how many bug reports and how social media/reddit/news sites will react to this. Think about frustration. Think about standards. Think about <You name it>.

tbh, I see that this "evolution" is almost like killing every single thing people have learnt through the several past decades, with no real real benefit. Just simplifying what is already simple. Complicated UIs? Not my thing. I'd prefer working on my store software that many don't even use.

And one more thing, please please please, think about medium/large scaled software before changing anything. You can have nothing for a simple calculator (not even KCalc), but what about digiKam/KDevelop/Kdenlive/Krita/KStars/PIM suite?

Thank you.

And what would happen to menus? How will that centered toolbar look with menus on the left?

Probably better, because you won't have all the UI elements clustered on the left with a bunch of whitespace on the right. However I want to emphasize that the "separate the toolbar button groups with whitespace" idea is just that: an idea. And if it were implemented, it would be optional rather than replacing vertical separators (we're KDE, after all!) and presumably would only be adopted in the apps where it makes sense. If it looks bad, you don't use it. If it looks good, you use it. Simple as that.

How it will work with KDevelop for example?


Or Krita?

Presumably these apps wouldn't adopt them because they're already crammed with buttons and there's no whitespace left. Also these are super extreme examples. Pro apps have different needs from other apps.

What about changing a thing almost +80% of people are used to? (Windows/Linux)
Think about how many bug reports and how social media/reddit/news sites will react to this. Think about frustration. Think about standards. Think about <You name it>.

Actually, people are already frustrated with the KDE-style UI design. I hear this constantly. It's "dated". It's "clunky", it's "designed by programmers". And so on. This effort aims to fix that. But we're not doing it to make people on social media happy; rather, people on social media have in this case identified a real problem. We're doing it with the goal of fixing that problem, not with making people happy. We hope that will happen as a side effect. :)

tbh, I see that this "evolution" is almost like killing every single thing people have learnt through the several past decades, with no real real benefit. Just simplifying what is already simple. Complicated UIs? Not my thing. I'd prefer working on my store software that many don't even use.

Not sure what you mean by this, really. Our "Windows/Linux" competitors already implement most or all of the proposed changes: no extra borders around windows; left sidebars separated from the content view with a single-pixel line; a unified title and toolbar area; checkboxes with checkmarks in them; window shadows that get smaller for inactive windows. These changes will makes things better for UI familiarity, not worse.

And one more thing, please please please, think about medium/large scaled software before changing anything. You can have nothing for a simple calculator (not even KCalc), but what about digiKam/KDevelop/Kdenlive/Krita/KStars/PIM suite?

Absolutely. Thankfully, as previously mentioned, most of the changes we're proposing don't impact those kinds of apps at all, or impact them in only small positive ways (IMO).

Thank you.

You're welcome!

ndavis added a comment.Jun 2 2019, 2:10 AM

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

+1, that's a great idea. What is the difference between "whitespace" and "expanding whitespace" though? Is the former a fixed width? If so, when would we use that instead of a separator?

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

+1, that's a great idea. What is the difference between "whitespace" and "expanding whitespace" though? Is the former a fixed width? If so, when would we use that instead of a separator?

Correct. The idea would be to use it instead of a vertical line separator when there's plenty of room in the toolbar. But for really packed toolbars, as @safaalfulaij brings up, the existing vertical line separators would be better. Heck maybe the whitespace separator could even turn into a line separator when the window is resized to be very narrow.

michaldybczak added a comment.EditedJun 2 2019, 7:26 AM

I love this whitespace/expanding whitespace idea. It looks like I have a very similar sense of aesthetics as Nate so I'm agreeing with all his posts above. Kvantum themes can group toolbar buttons already and then the screenshots usually make a huge impression because with so many changes the whole Plasma feel is strongly altered, so people complaining about KDE look or those preferring Gtk look are interested in it, because it finally looks more in line what they are expecting.

I like the default Breeze look and I think it's quite modern and good but it has its lacks and I do agree that in many cases Gtk look is superior (when the look on a case of a singular app, in overall Gtk theming, is an inconsistent disaster), so those Ned's proposals are heading in the right direction. And of course, as he said, those elements would be optional and probably not the default (at least not for some time).

With so many theming changes it would be nice to prepare a good wiki article about Plasma theming because currently, this is a steep and very frustrating learning curve for newbies. Each DE has its own ideas and implementation of how theming is applied and this creates even greater confusion if someone already got used to Gnome's or XFCE's style of theming. It's hard to wrap around what setting influences what so people are lost. Us, long time Plasma users, feel comfortable and we can adjust Plasma to our liking so Breeze limitations are not an issue, but for many if not the most, this level of expertise is not possible to achieve in short time so people often bounce off and go back to DE they were used to.

felixernst added subscribers: broulik, felixernst.EditedJun 2 2019, 9:54 AM

Here's another idea I've heard bandied about: create new "whitespace" and "expanding whitespace" items

I am a big proponent of expanding whitespaces and have suggested one six weeks ago in regards to Dolphin (here). Back then two people total commented on the "expanding whitespace" in particular:

In the VDG chatroom on IRC, @broulik wrote:
I like the split tool bar, since it also makes it more consistent with the file dialog.

In a forum thread, long-standing forum member airdrik wrote:
I like the spacer idea and would suggest that be made available for all applications.

Outside of Dolphin as well I think expanding whitespaces are in many cases the easiest way to make the user interface more clear/overseeable.

Heck maybe the whitespace separator could even turn into a line separator when the window is resized to be very narrow.

+1. Whitespaces communicate an arguably stronger separation than the existing line separators. This separation should not get lost when the whitespace size becomes very small.

ngraham updated the task description. (Show Details)
cblack added a subscriber: cblack.Jun 7 2019, 12:10 AM

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

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


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

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

Discover w/ Breeze Dark & Paler Colors

Discover w/ Breeze Default

Discover w/ Breeze Dark

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

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

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

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

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

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

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

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

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

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

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


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

In T10891#187828, @mglb wrote:

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

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

In T10891#187828, @mglb wrote:

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

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

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

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

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

{F6844666}

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

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


Or Krita?

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

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

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

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

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

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

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

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

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

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

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

Some examples:

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

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

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

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

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

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

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

I see two solutions for this problem:

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

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

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

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

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

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

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

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

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

johan.boule added a comment.EditedSun, Jul 28, 2:56 PM

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

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

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

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

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

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

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

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

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

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

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

I'm guessing you mean Windows ;)

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

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

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

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

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

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

johan.boule added a comment.EditedSun, Jul 28, 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.EditedSun, Jul 28, 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.Sun, Jul 28, 8:53 PM
KonqiDragon added a subscriber: KonqiDragon.EditedMon, Jul 29, 9:02 AM

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

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

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



But on the left is looks too flat.

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

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

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

ngraham moved this task from Backlog/Planned to Sent to dev on the VDG board.Fri, Aug 2, 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.Sun, Aug 4, 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.EditedFri, Aug 9, 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.EditedSat, Aug 10, 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.EditedSat, Aug 10, 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.