For Plasma 5.5 we'd like to give Breeze a round of polish updates; the melting pot put together a great design, but it's no secret that there are many small inconsistencies within the look and feel of Plasma right now. For example, some widgets have outlines, some don't. We have "highlight" lines with different strokes. It's also pointed out we have issues of awkward or inconsistent spacing. Some things have rounded corners, others don't.

So, it's time to refine. While many of our widgets look good alone, this update is to ensure widgets work together as a cohesive whole. For this release, I believe we can get the rules down and apply them across the 3 staples of the Breeze base; the window decoration, the widget theme, and the desktop style. If we can, we should also start looking at major individual components such as desktop widgets and some applications on a case-by-case basis if they have significant exposure. For example. some of our system tray popups have incorrect padding, and the system settings overview is still has a hardcoded oxygen-style overview.

This isn't for huge changes, but if it's worth re-visiting some individual components to see how they might be revised we can do that. For example, Kate almost has more "Breeze" tabs than Breeze. We can also look at defaults and alternatives and see if anything should be tweaked in those areas, too. If there are gripes with the style as it is, or changes you routinely make, this is the best time to air your laundry. Essentially, now that we've had some time to use this style we can start pointing out things which might be done better.

If I had one request to make, it's to not look at individual widgets as much, but look more at the rules as a whole and how they're applied. E.g. "The radius of corners should be 3px for containers, and 2px for widgets", "all lines should be 20% transparent", "This component isn't following our rule on stroke positioning", "the HIG says we should do X", or "the padding on this widget is 1px off".

I'll try to provide mockups and designs of the changes as we accumulate them. I'll also be working on areas where the HIG and design guidelines aren't already enforced.

Finally, we should also look at accessibility Breeze and how we might integrate accessible options consistently.

Welcome to the Breeze Nitpicking Polish Thread!

Hi Kver,
Excellent initiative, with which I fully agree. Count me in for any polish needed on the style and decoration.
I could
- comment on issues and offered solutions
- code

Best regards,

Hugo

I'd appreciate if Breeze Dark get some love. In particular it's hard to distinguish two windows from each other, esp. in bright conditions, since the title bar has almost the same color as the background. Similarly the thumb of scrollbars is hard to perceive.

Hello,

I'm a bit confused with what's in the scope of this review and what isn't. For example, the Configure Shortcuts dialog has both awkward UI (powerful by default, I'd say) and visual glitches (zeroed margins), see this screenshot. Is it out of scope because not caused by the Breeze theme ?

Another problem that half-belongs to this thread : the "New Document" toolbar button in LibreOffice uses 2px-wide strokes.

BTW, Kate-like tabs everywhere would be great. The main difference is the need to keep the grouping feature of the tab widget (if not in documentMode), which shouldn't be too hard.

Louis

Edit: Fixed shortcut URL.

louis94 wrote:Hello,

I'm a bit confused with what's in the scope of this review and what isn't. For example, the Configure Shortcuts dialog has both awkward UI (powerful by default, I'd say) and visual glitches (zeroed margins), see this screenshot. Is it out of scope because not caused by the Breeze theme ?

Another problem that half-belongs to this thread : the "New Document" toolbar button in LibreOffice uses 2px-wide strokes.

BTW, Kate-like tabs everywhere would be great. The main difference is the need to keep the grouping feature of the tab widget (if not in documentMode), which shouldn't be too hard.

Louis

So, this is probably going to fall into 2 phases, ideally hitting one phase per release - but if anyone wants to jump-ahead I'm not stopping you! This is just the evil scheme I've concocted.

The first phase will tackle things in the Breeze widget style, Breeze window decorations, and the plasma desktop Breeze style. Anything really "broad brush". It won't cover individual icons because those are already receiving significant amounts of effort, and also because we can't quite scale changes in the same way; if an icon has an issue I recommend filing a bug report. Mainly this is for any low-hanging-fruit or papercuts.

The second phase will be hitting prominent applications and widgets under the KDE/Plasma umbrella. For this, it will be going through each item on a case-by-case basis and making sure they follow standards and don't hit some of the common pit-traps (such as hard-coding a font colour). This is things like getting spacing issues in individual apps/widgets sorted out, making sure things aren't hardcoded, and maybe light layout changes to oddly structured interfaces.

Heiko Tietze wrote:I'd appreciate if Breeze Dark get some love. In particular it's hard to distinguish two windows from each other, esp. in bright conditions, since the title bar has almost the same color as the background. Similarly the thumb of scrollbars is hard to perceive.

Sounds good to me!

hugo.pereira@free.fr wrote:Hi Kver,
Excellent initiative, with which I fully agree. Count me in for any polish needed on the style and decoration.
I could
- comment on issues and offered solutions
- code

Best regards,

Hugo

Excellent! This is going to be a lot of small changes, so I imagine with your familiarity on the codebase will make the individual tweaks childs-play.

Kver wrote:Sounds good to me!

Great. Here is a screenshot to illustrate the issue.


The thumb problem is related to the Gtk theme but the rest should be clear. From back to front: Firefox, Kate, KSystemsettings.

I have a (hopefully) very small request.

In the screenshots I noticed that the COPYING etc. files have a ® in their icon. That’s a registered trademark sign, not a copyright sign and as a lawyer it bugs me a lot.

I strongly suggest that we either use either the © sign in those icons, or if we really want to point out that those files are not just about copyright, but maybe even patents and trademarks, use the § sign.

Heiko Tietze wrote:

Kver wrote:Sounds good to me!

Great. Here is a screenshot to illustrate the issue.
*screenshot*

The thumb problem is related to the Gtk theme but the rest should be clear. From back to front: Firefox, Kate, KSystemsettings.

So, I imagine we have a few options for this;

• Right now windows have a slight outline which helps cement the decoration shadow, which is tied to the shadow colour. If we switched it to the widget outline colour it would become light for dark themes (giving contrast), and on Breeze it would just continue to emphasize the shadow.
• We can look at using an oxygen-style glow when a dark theme is enabled. I believe this would be a change in the provided dark-theme pallet. To avoid annoying people we might consider adding this as a second dark variant.
• We can look at better defaults for active/inactive application pallet variations, making the inactive windows a different tone. This would only help the active window though.

My vote is modifying the semitransparent outline on windows; the specification makes the outline opacities at either 60%, 40%, or 20% increments, I think it's sitting at 20%, so we can also looking at bumping it up to 40%.

hook wrote:I have a (hopefully) very small request.

In the screenshots I noticed that the COPYING etc. files have a ® in their icon. That’s a registered trademark sign, not a copyright sign and as a lawyer it bugs me a lot.

I strongly suggest that we either use either the © sign in those icons, or if we really want to point out that those files are not just about copyright, but maybe even patents and trademarks, use the § sign.

I don't know if this is within the scope of the Breeze nitpicks; maybe start a new thread (with the screenshots in question)?

Kver wrote:I don't know if this is within the scope of the Breeze nitpicks; maybe start a new thread (with the screenshots in question)?

Done:
viewtopic.php?f=285&t=127678

Kver wrote:

Heiko Tietze wrote:

Kver wrote:Sounds good to me!

Great. Here is a screenshot to illustrate the issue.
*screenshot*

The thumb problem is related to the Gtk theme but the rest should be clear. From back to front: Firefox, Kate, KSystemsettings.

So, I imagine we have a few options for this;

• Right now windows have a slight outline which helps cement the decoration shadow, which is tied to the shadow colour. If we switched it to the widget outline colour it would become light for dark themes (giving contrast), and on Breeze it would just continue to emphasize the shadow.
• We can look at using an oxygen-style glow when a dark theme is enabled. I believe this would be a change in the provided dark-theme pallet. To avoid annoying people we might consider adding this as a second dark variant.
• We can look at better defaults for active/inactive application pallet variations, making the inactive windows a different tone. This would only help the active window though.

My vote is modifying the semitransparent outline on windows; the specification makes the outline opacities at either 60%, 40%, or 20% increments, I think it's sitting at 20%, so we can also looking at bumping it up to 40%.

I am confused.
From the screenshot, are we talking about the shadow ? Or about the titlebar vs content background color ?
In non-dark breeze, there is a strong contrast between titlebar background and window content background for the active window.
Why is it not the case for the dark-breeze color scheme ? (From what I understand in the dark breeze, the active and inactive decoration's titlebar color is the same)
Maybe one should start by setting a "light" titlebar color for the active window in breeze.

For the shadow, implementing a "glow" for the active window (as in oxygen) is also doable of course, and this, disregarding whether we use a dark or non dark color scheme ... The only difficulty with this is: what color should we use for such glow ? The selection (=blue) color ? A completely different color ? Where should is be set ? as part as the color palette (which is not so trivial to implement) ? As part as the decoration's settings (as was the case with oxygen, but then people complained it was disconnected for the color palette) ? etc.

Oppinions welcome

Hugo

I hereby submit checkboxes for a revision. XD
I think our original intend was good, but in practise it is too confusing. Personally I feel they should be trimmed down in size every so slightly and we should return to the traditional checkbox paradigm.

hugo.pereira@free.fr wrote:I am confused.
From the screenshot, are we talking about the shadow ? Or about the titlebar vs content background color ?
In non-dark breeze, there is a strong contrast between titlebar background and window content background for the active window.
Why is it not the case for the dark-breeze color scheme ? (From what I understand in the dark breeze, the active and inactive decoration's titlebar color is the same)
Maybe one should start by setting a "light" titlebar color for the active window in breeze.

For the shadow, implementing a "glow" for the active window (as in oxygen) is also doable of course, and this, disregarding whether we use a dark or non dark color scheme ... The only difficulty with this is: what color should we use for such glow ? The selection (=blue) color ? A completely different color ? Where should is be set ? as part as the color palette (which is not so trivial to implement) ? As part as the decoration's settings (as was the case with oxygen, but then people complained it was disconnected for the color palette) ? etc.

Oppinions welcome

Hugo

Ah, I was thinking of the overall problem that title-bars blending in was a result of no contrast between the higher and lower windows as a whole. If someone likes the 'slate' look where windows are a single colour, then I was making my provision based on that. But I may have been confused about what you meant.

Anyway, for the settings of the thing, I would default to whatever colour the widget outlines are (the ones found on buttons); which tend to be dark for light themes and light for dark themes. If we want to get 'crazy' with it maybe have a dropdown or a checkbox in the settings which toggles between "traditional shadow" (always dark), "smart shadow" (uses outline colour, new default), and "glow" (focus colour). I don't think we need to implement a full-on colour-picker like Oxygen did.

Alternatively, we could keep the shadow dark on any setting, and only apply these colours to the subtle 1px outline around the window. So, here's some specimens for what I was thinking with shadows. These aren't 100% accurate, but here's what I've got:

A) The current shadow style. 10% black outline, 20% opacity shadow.
B) Doubled the opacity of outline and shadow.
C) Pulls the outline colour from the button widget outline colour.
D) Same as C, only the outline fades out at the top, avoiding "muddy looking" titlebars for non-slate variants.
E) Oxygen-style glow based on "focus colour"
F) Outline uses focus colour, but keeps dark shadow




My personal favourite is a combination of C and D. Just like we decide to draw the separator based on whether or not the windows are using a "slab" colour scheme, we could alternate between C and D based on that as well. Use C when we have slab-style windows, and D when the titlebar is different than the window background.

Sogatori wrote:I hereby submit checkboxes for a revision. XD
I think our original intend was good, but in practise it is too confusing. Personally I feel they should be trimmed down in size every so slightly and we should return to the traditional checkbox paradigm.

* Kver agrees. Also, we need to look at sizing in general; text-boxes are 2px taller than comboboxes. We also have a really weird animation for checkboxes which feels weird.

Am I allowed to copy your mockup as a task on phabricator, Ken?