Regarding Dark Breeze:
- Panels have a white line separating it from the desktop, which looks not so nice: Pic
- System settings has some sort of bar effect in the background: Pic

hugo.pereira@free.fr wrote:Also: (and this is only a personal opinion), I really do not think of 2pixels outline as breezy at all. (and dislike them quite some, pretty much as much as bold font). They look fat, uncrisp and too much in the face (again: personal opinion). In fact, from the beginning, the "current" breeze has evolved towards using less and less two pixels outline for this reason. (the only place where one remains are in sliders, though I'd personally like to get rid of it here too). Your design "polish" is basically reverting these changes (many of them to what they were originally)

When I first seen the mockups, I had the same reaction. The 2px outlines were just like bold text to me. Now that I've been playing with the style for a week or so, I turned my mind: the 1px borders on hover look too thin. They are even difficult to see on check boxes and radio buttons. Used with care, 2px highlights add a touch of bright colour to an otherwise greyish theme. As SVGs are meant to showcase widgets in as many states as possible, I don't think one may state that a colour is overused after having looked at them.

Louis

subdiff wrote:Regarding Dark Breeze:
- System settings has some sort of bar effect in the background: Pic

This is "built-in" system settings. Is not specific to breeze, nor to dark. (it also there in the light theme)
I agree it should go (it just looks dirty).

And in fact, the whole "sectioning" is pretty wrong. It is hard coded in the application and is more "oxygen" than breeze.

But then, if systemsettings is redesigned (when is that happening ?) ...

Kver wrote:Either way what's most important (to me, anyway) is that the theme is internally consistent, and that it looks less like a patchwork of ideas. Right now we have 2px highlights, fills, gradients, no gradients, 1px outlines, no outlines, white grabbers, dark grabbers... It needs to be reeled in. I experimented with using the light blue fills in a very early draft, but outside of buttons and sliders the fill method can't be applied universally. When a fill looks good for a button but doesn't work so much for a checkbox or an input - I'd push to have widgets work together more than be like "this looks good for buttons", "this looks good for inputs", etc. It lands us with a patchwork of "this looks goods for"s with no real overarching design goal.

Just kicking in on the inconsistency part:

- Where is there 2px highlight in latest breeze ? unless I missed it it is only used for sliders. Did I miss other places
- gradients: only the active window titlebar background, and buttons, have gradients. Or did I miss others ?
- white grabbers ? you mean sliders again, as opposed to scrollbars ? (dark grabbers)

hugo.pereira@free.fr wrote:

Kver wrote:Either way what's most important (to me, anyway) is that the theme is internally consistent, and that it looks less like a patchwork of ideas. Right now we have 2px highlights, fills, gradients, no gradients, 1px outlines, no outlines, white grabbers, dark grabbers... It needs to be reeled in. I experimented with using the light blue fills in a very early draft, but outside of buttons and sliders the fill method can't be applied universally. When a fill looks good for a button but doesn't work so much for a checkbox or an input - I'd push to have widgets work together more than be like "this looks good for buttons", "this looks good for inputs", etc. It lands us with a patchwork of "this looks goods for"s with no real overarching design goal.

Just kicking in on the inconsistency part:

- Where is there 2px highlight in latest breeze ? unless I missed it it is only used for sliders. Did I miss other places
- gradients: only the active window titlebar background, and buttons, have gradients. Or did I miss others ?
- white grabbers ? you mean sliders again, as opposed to scrollbars ? (dark grabbers)

• Yep, I was referring to the ones used on sliders - I'm not sure if they're present anywhere else. Not part of the theme, but Kate as I mentioned is using this style for tabs as well. On the desktop theme we also have 3px lines serving as highlights too. :/
• On the titlebars, last time I checked (and this was a while ago, might have been updated) the gradient code was actually configured to use the same colour on both ends... This was a long time ago, in a development branch, but that might have been a thing. I remember because I had fixed it in the old Chroma deco experiment, at the time assuming is was intentionally flattened with the code kept for posterity / future config.
• I was referring to the actual grabbable part of the widgets. Granted, I was also awake for 20 hours at that point, so I was slightly out of it and willing to make up names to finish my post. I'm also not an expert in.. *snaps fingers* nameology!

EDIT: On a side note I was thinking hard about your post, and at minimum I think we need allow Breeze to be configured to look similar to its current appearance. Like you said, this is turning into a rewrite - people attached to the current look should have a quick option to change back some of the more obvious changes.

EDIT EDIT: On a side side note, I apologise if I was being a tad stubborn in my last post.

So I've read through the thread and I like what I see. I'll definitely keep an eye on these changes to readily incorporate them into Breeze GTK. That said, I also have some opinions that I share with others here that I'd like to reiterate.

1) I completely agree that we need consistent widgets as it will set a precedent that will make other design issues all the more apparent (padding, unusual organization without any reason, etc). I think it would be impossible to defend a disparate aesthetic within Breeze.

2) We need flush edges on highlighted menu entries. Having a slight space between the sides and rounding the inner edge creates unnecessary tension and draws attention to all the wrong places.

3) 4 px outlines (at 180 dpi) are a bit tough for me to swallow. I acknowledge that they will be infrequent in actual use, thereby reinforcing their meaning, but it still feels like there may be a 'Breezier' way to achieve a similar effect. I've nothing to show at the moment, but it could just be an emotional attachment to the way things are. I'm not against trying it for a release to see if sticks.

4) I think Breeze stands out as a 'lite' theme without a complete loss of dimension, and that's something I'd like to explore. I love that Breeze is a practical theme with lots of character. There's plenty of room for clean details that aren't flat versions of existing designs, which why I'd like to keep some variation of the current checkboxes and the full-color fill on focused buttons if we can make them fit. I'd even advocate for keeping the slight gradients on buttons if it didn't present serious hurdles to reaching a consistent look. Again, I have no visual proposals but I'm more concerned about keeping that spirit of utility + charm.

Additionally, while we could introduce configuration for these smaller changes, I think we should avoid doing that often since it could be difficult to maintain in Qt and essentially impossible for Breeze GTK (not that we should make sacrifices for the GTK versions). I heard an idea for having multiple distinct themes that pursue different aesthetic goals back when Plasma 5 began; Even though there aren't enough resources for that I feel it's preferable to eventually throwing the kitchen sink into Breeze via options.

Hello,

My "fun to play with" thing is back. It is based on the latest mockup from Kver and displays interactive widgets in your browser. Just extract the archive and open KDE/combo.html in Firefox (no interactivity in Chromium because of a stronger security policy). It is not dpi-aware; differences to the mockup are listed below:

• Active button labels aren't white. Rationale: The icon colours don't change.
• No spacing between menu items, and smaller icons. Rationale: 1) Less mouse movement 2) Many menus are quite long, they should fit in the screen.
• Some colours may not be exactly the same as in the mockups. This is just me copying.
• Interactivity isn't nearly as good as with real-world widgets.

Sidebar
I'm a bit worried of the selected sidebar item not being visible enough. Blue is used for selection everywhere else, which makes the grey background difficult to understand. The focused variant (blue background) is also inconsistent with other widgets. Technically, the focus is on the sidebar, not the item; one can not tab through items. In general, focused list items don't make sense at all.
I'd go the following way (and I'll eventually post screenshots):

• The selected item gets the blue highlight.
• When focused, the sidebar gets a 2px border (on all four sides).

Tabs
Kate-style tabs (variant #3) work best in document mode when they are just under the window decoration. Add a menu or a toolbar and they feel a bit broken. The classic variant (#1) would be great to have on DWD, but they aren't as good as #3 when below the windeco. The OS X-style variant (#2) would be worth a try for Gwenview/Calligra Word's tabbed side panels or in configuration dialogs. It may not work with KDE's alignment guidelines (because widgets are not centered as in OS X), and I'm curious to see how the close button would look on these (a button inside a button ).
My current preference is #3 for document mode and #1 for anything else.

Nitpicking

• Breadcumb focus is broken (invisible) in at least Dolphin and Gwenview. I guess it's app-specific.
• The default button (in dialogs, the one fired when you hit enter) isn't sufficiently highlighted. It should be visually different from a focused/hovered button while still being readable.

Louis

ScionicSpectre wrote:
2) We need flush edges on highlighted menu entries. Having a slight space between the sides and rounding the inner edge creates unnecessary tension and draws attention to all the wrong places.

You mean: http://wstaw.org/m/2015/08/27/plasma-desktopcC7240.png ?
If yes, I have been playing with this locally. There was some difficulties in dealing with the menu rounding at the top and bottom of the menu, which I think I fixed.
If we agree, this could go in rather quickly. (I'll ping Andrew too on this)

ScionicSpectre wrote:Additionally, while we could introduce configuration for these smaller changes, I think we should avoid doing that often since it could be difficult to maintain in Qt and essentially impossible for Breeze GTK (not that we should make sacrifices for the GTK versions). I heard an idea for having multiple distinct themes that pursue different aesthetic goals back when Plasma 5 began; Even though there aren't enough resources for that I feel it's preferable to eventually throwing the kitchen sink into Breeze via options.

Agreed on this.

Also it would feel as if we actually hesitate about our visual identity (the same was argued against for Oxygen), which is not what we want. Breeze is not QtCurve, IMHO.
Don't get me wrong: QtCurve is really great, it is just not the same target. It basically puts the style's design in the end of the user, which, again, is not what I think we are trying to achieve.

Best,

Hugo

hugo.pereira@free.fr wrote:

ScionicSpectre wrote:
2) We need flush edges on highlighted menu entries. Having a slight space between the sides and rounding the inner edge creates unnecessary tension and draws attention to all the wrong places.

You mean: http://wstaw.org/m/2015/08/27/plasma-desktopcC7240.png ?
If yes, I have been playing with this locally. There was some difficulties in dealing with the menu rounding at the top and bottom of the menu, which I think I fixed.
If we agree, this could go in rather quickly. (I'll ping Andrew too on this)

ScionicSpectre wrote:Additionally, while we could introduce configuration for these smaller changes, I think we should avoid doing that often since it could be difficult to maintain in Qt and essentially impossible for Breeze GTK (not that we should make sacrifices for the GTK versions). I heard an idea for having multiple distinct themes that pursue different aesthetic goals back when Plasma 5 began; Even though there aren't enough resources for that I feel it's preferable to eventually throwing the kitchen sink into Breeze via options.

Agreed on this.

Also it would feel as if we actually hesitate about our visual identity (the same was argued against for Oxygen), which is not what we want. Breeze is not QtCurve, IMHO.
Don't get me wrong: QtCurve is really great, it is just not the same target. It basically puts the style's design in the end of the user, which, again, is not what I think we are trying to achieve.

Best,

Hugo

I also agree 100% on this, especially in the sense that having a theme with "uber-configuration" is a mistake. Whatever we produce, once it has an identity maybe we should just be willing to say "this is it" and limit tuning to things like usability settings. Strip out the various draw options which are purely stylistic, and ask what functional purpose a setting might have before inclusion assuming that the appearance has to be somehow broken to a user to warrant changing the settings. The options I can see including would be...

• High-contrast / darker borders (for the visually impaired)
• Simple spacing adjustment options like "comfy/compressed" (for users of small netbooks where space is at a premium)
• Keyboard assistants (for persons who cannot use mice, a combination of keyboard accelerators and more prominent focus indicators)

... And not a whole lot else.

In this vein and the ideal of having different styles, one thing we might want to consider is not outright replacing the existing Breeze theme - but perhaps packaging the new theme alongside the current one. In the settings the widget styles might be referred to as "Breeze Classic" and "Breeze Contemporary", or "Breeze" and "Breeze 2" or "Breeze Next".

@Hugo; super nice to know you've been experimenting with flush menus/highlights.
@Louis94; I love the evolution of your "fun to play with thing" and I'm fully behind your points, especially since each one is very well justified.

About the only one I'm kind of on the fence about is the black-text-on-blue; I beleive highlight effects can be applied to the icons, they just don't work for Breeze... As much as I really agree with your point, on a usability level we might need to cede style for accessibility. Also, when you hover over just about anything else, we're still turning the text white. :/

On your point with the sidebar, when you look at it like a selection and not just a grouping of arbitrary buttons I think we actually need to take your idea further; I know this is going back into the direction of Oxygen, but instead of the tinted background we should probably treat it more like a menu with a white background and widget-style border. We'll still attach it to the edge, but yeah - it's really not just a groupbox - the whole thing is a widget.

I think the next step is to create a design based on the cumulative feedback we've got going; I'll make some variants when I get the chance, one with a "fill-oriented" design and one with the simple gradients re-introduced in a consistent way (all clickables?). Then we can fling some poop around and decide what is the the best. Once we have the pros/cons from that, I'll make one iteration based on the combined feedback of the variants, and then a final target to aim for... Sound alright?

Beyond that, I think this is our laundry list;

• Codify our height/spacing, make sure that things will always line up perfectly when implemented properly.
• Maybe take a more formal look at windecos. I don't see them changing much.
• The workspace style, which, again, I don't see changing much.
• Begin hammering out spacing issues on high-profile components and plasma widgets. Wipe out those complaints on Reddit and comment sections once and for all.

EDIT: @Hugo; Question! Tableviews on Breeze have the scrollbar going all the way up the widget, including the headers. This is really terrible looking since it gives the tableviews a reverse "L" shape - do you know if this is something that can be changed?

@Hugo Yes, that menu looks great (it should also be simple to implement on the GTK side). As for the rounded inner corner, I was mostly reiterating what Sogatori had demonstrated so well in this image:



Rounding the highlight area itself only multiplies the unwanted attention in that area. Rounded corners on the menu itself, however, certainly make sense and their radius should closely match similar elements. Additionally, if we can't fill the corners for highlighted entries at the bottom or top of a rounded menu, we should leave enough white space to avoid distraction:



Of course, if we go for the rounder corners it may not be necessary to add any space at all since there would presumably be a few more pixels by default.

@Kver I agree that any options within Breeze should be be relevant to accessibility and usability rather than stylistic choices. I also think your laundry list is spot-on and a good point of focus for further discussion. I really appreciate all the mockup work you've done and I'd love to see the variants you mentioned.

EDIT: @Hugo; Question! Tableviews on Breeze have the scrollbar going all the way up the widget, including the headers. This is really terrible looking since it gives the tableviews a reverse "L" shape - do you know if this is something that can be changed?

I am not sure what you mean by "reverse L shape" (screenshot would add).
Anyway, it is built in Qt and hard to change. Also, you do not want the header to be "above" the scrollbar, right ? You would rather like an "empty area" on top of the scrollbar, and right of the header, in a way that is similar to the "empty corner" between vertical and horizontal scrollbars.
This in particular is quite hard to implement.

ScionicSpectre wrote:@Hugo Yes, that menu looks great (it should also be simple to implement on the GTK side). As for the rounded inner corner, I was mostly reiterating what Sogatori had demonstrated so well in this image:



Rounding the highlight area itself only multiplies the unwanted attention in that area. Rounded corners on the menu itself, however, certainly make sense and their radius should closely match similar elements. Additionally, if we can't fill the corners for highlighted entries at the bottom or top of a rounded menu, we should leave enough white space to avoid distraction:

There is some confusion. I do want to keep the selection square (as in the screenshot you sent), for exactly the reasons you mention.
The issue was only for the "first" and "last" item, which overlap with the menu corners itself. Indeed one can add space, as your last screenshot shows, to prevent the confict, or (and I think that is more elegant), one can "round" the relevant corners of the selection for just these two items.

See screenshots:
- middle item: http://wstaw.org/m/2015/08/28/menu-highlight-0.png
- first item: http://wstaw.org/m/2015/08/28/menu-highlight-1.png
- last item: http://wstaw.org/m/2015/08/28/menu-highlight-2.png

What do you think ?
(personnally, I like it. The only drawback if you want, is that now the margins between a menu and its menu-items is reduced with respect to what we have now, by ~ 2 pixels)

Kver wrote:
I also agree 100% on this, especially in the sense that having a theme with "uber-configuration" is a mistake. Whatever we produce, once it has an identity maybe we should just be willing to say "this is it" and limit tuning to things like usability settings. Strip out the various draw options which are purely stylistic, and ask what functional purpose a setting might have before inclusion assuming that the appearance has to be somehow broken to a user to warrant changing the settings. The options I can see including would be...

• High-contrast / darker borders (for the visually impaired)
• Simple spacing adjustment options like "comfy/compressed" (for users of small netbooks where space is at a premium)
• Keyboard assistants (for persons who cannot use mice, a combination of keyboard accelerators and more prominent focus indicators)

... And not a whole lot else.

On the high-contrast option: there is already one !
It is in the "colors->options->contrast". panel
It was used for oxygen, and is not (yet) for breeze. This is just a coding issue. Need to take the corresponding config value, and change all color calculations according to it. I'll give it a shot.
Note that it has more steps than the 20% 40% 60% opacities from the guidelines. Will need to improvise.

Kver wrote:About the only one I'm kind of on the fence about is the black-text-on-blue; I beleive highlight effects can be applied to the icons, they just don't work for Breeze... As much as I really agree with your point, on a usability level we might need to cede style for accessibility. Also, when you hover over just about anything else, we're still turning the text white. :/

On the coloring of icons, I have implemented a basic one for "selected items" and "focused buttons" in my local version of breeze.
See: http://wstaw.org/m/2015/08/28/colorize-icons.png

It looks gorgious, but obviously has limitations.
1/ works only for monochrome icons
2/ cannot make any distinction between colors: the style only knows about pixmaps (think: png), and not svgs.
3/ it does not work for icons in "lists" (think: dolphin) because here we do not have easy access to what's rendered inside the list item. Beside, not all icons in such lists ae monochrome, even in breeze.

Because of 1/ we need to make sure the said coloring is an option that can be switched on/off, and that there is no "bug" in the applications (that is: that no colored icons are used for buttons and menus).

2/ is something we can't do anything about. For instance the red "quit" monochrome icon gets colored in white just like any other. I do not think this is an issue though. again, assuming that only monochrome icons from breeze are used in menus and buttons.

Comments welcome

Hugo

hugo.pereira@free.fr wrote:

Kver wrote:See: http://wstaw.org/m/2015/08/28/colorize-icons.png

Because of 1/ we need to make sure the said coloring is an option that can be switched on/off, and that there is no "bug" in the applications (that is: that no colored icons are used for buttons and menus).

2/ is something we can't do anything about. For instance the red "quit" monochrome icon gets colored in white just like any other. I do not think this is an issue though. again, assuming that only monochrome icons from breeze are used in menus and buttons.

Comments welcome

Hugo

Colored icons would be awesame and also needed for plasma eo. when the user select an dark theme the light breeze icons doesn't fit.

1/ there were use colored icons in buttons and menus (e.o. notification icon in the menue) but it is not the norm.

does it helps that breeze only have to switch two colors 4d4d4d to f2f2f2ff and b3b3b3ff to f9f9f9ff. but again it have to be solved also for different plasma desktops.

I think gnome change the background depanding on the background maybe we can do the same way. (I have no idea)