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 - in progress: 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

There are a very large number of changes, so older changes are hidden. Show Older Changes
ngraham triaged this task as Wishlist priority.May 6 2019, 6:34 PM
ndavis added a subscriber: ndavis.May 6 2019, 6:43 PM
abetts added a subscriber: abetts.May 6 2019, 6:45 PM

Looking good! Keep it up. Please address the concerns so that we can ship a good evolution.

Thanks! Which concerns would those be, exactly? Is there anything here you'd like to see changed?

abetts added a comment.May 6 2019, 6:48 PM

Thanks! Which concerns would those be, exactly? Is there anything here you'd like to see changed?

I think the main one is how things will interact in a tiled window environment. If there is a solution for that, then let's keep going.

Thanks! Which concerns would those be, exactly? Is there anything here you'd like to see changed?

I think the main one is how things will interact in a tiled window environment. If there is a solution for that, then let's keep going.

If you're referring to some of the concerns that came up in the "turning off the borders" discussion, see D13284#461617 and T8707#184088. To make a long story short, I don't think there are any blockers. Everything still works fine with window tiling and borders off.

abetts added a comment.May 6 2019, 6:51 PM

Thanks! Which concerns would those be, exactly? Is there anything here you'd like to see changed?

I think the main one is how things will interact in a tiled window environment. If there is a solution for that, then let's keep going.

If you're referring to some of the concerns that came up in the "turning off the borders" discussion, see D13284#461617 and T8707#184088. To make a long story short, I don't think there are any blockers. Everything still works fine with window tiling and borders off.

Then great! Let's carry on.

ndavis added a comment.May 6 2019, 6:54 PM
This comment was removed by ndavis.
fabianr added a subscriber: fabianr.May 7 2019, 7:25 AM
ngraham updated the task description. (Show Details)May 17 2019, 5:04 PM
ngraham updated the task description. (Show Details)
lavender added a subscriber: lavender.

I added T8755, I'm not sure how well it fits here but the idea would be to give the user more control over the accent color used by Breeze. Here are examples of how Windows 10 generates a palette based around the selected accent color and MacOS also slightly adjusts the colors, both lets user select the accent color.

sh4nks added a subscriber: sh4nks.May 20 2019, 6:12 AM
gikari added a subscriber: gikari.May 20 2019, 10:02 AM
This comment was removed by gikari.

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.

russh added a subscriber: russh.May 20 2019, 11:00 AM

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.

Excuse me, could you elaborate on this? What is controversial about it?

You can find the (lengthy) discussion here: T8707

where can I get this nice looking checkboxes in svg?

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

mglb added a subscriber: mglb.May 20 2019, 4:52 PM

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?

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.Sun, May 26, 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)Mon, May 27, 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.Sun, Jun 2, 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.EditedSun, Jun 2, 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.EditedSun, Jun 2, 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.Fri, Jun 7, 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.Fri, Jun 7, 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.Mon, Jun 10, 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.Tue, Jun 11, 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)Fri, Jun 14, 4:43 PM

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