Some of the widgets in context (but without focus handling) here in the top-level XML file (has to be viewed in FF).

I created a menu bar using menu #2 above and Adwaita-inspired menu highlights, but I don't think it looks good. Is this menu to be used in menu bars too, or just combo boxes ?

Bonus feature:
See the sidebar without menu. Just comment out lines 8-48 of combo.xml (surround them with <!-- and -->). Killing the status bar is also possible, but is currently a rare use case.

Edit: Fixed URLs

andreas_k wrote:the dolphin look will change in 5.4 so it looks nice too you only have to wait some days

from what I could see, the appearance of Dolphin in KDE application 15.08 (therefore to Plasma 5.4 in QT5) seems to me the same as before.
Or am I wrong?

Free space in Dolphin 15.08.

louis94 wrote:Some of the widgets in context (but without focus handling) here in the top-level XML file (has to be viewed in FF).

I created a menu bar using menu #2 above and Adwaita-inspired menu highlights, but I don't think it looks good. Is this menu to be used in menu bars too, or just combo boxes ?

Bonus feature:
See the sidebar without menu. Just comment out lines 8-48 of combo.xml (surround them with <!-- and -->). Killing the status bar is also possible, but is currently a rare use case.

I hope you don't mind if I experimented with your work.

On your work with the menu, I think the main issue was that you weren't using background-clip to let the rgba border take full effect. Here's what it looks like with a few minor tweaks:
(scaled so it's easy to see what's happening)


One thing I also did was adjust the shadows. I think when it comes to shadows I think Sogatori was onto something in considering the 'planes' things are on when it comes to how things are positioned on the Z-Axis.

In you demo I tweaked it so windows have a much larger and softer shadow (closer to what you might see on a mac) which places them higher above anything they overlap. Menus have a moderate shadow at 8px softness, placing them above widgets. Then, of course widgets have the most shallow shadows, placing them above the chrome they sit on. I also switched the buttons and inputs to no gradients, instead using inner shadows for input boxes. Below is the result:


(click to download XML)

I also messed with the 2px borders, but that was just me playing. Ignore them. I did convert more hardcoded colours into rgba colours though.

Also, I'll go back to my SVGs. You just make fun things to play with, and I'd like to see you try to get the full interaction model in there. On thing though; I don't know if it's Firefox not playing nice with XML, but it seems like border transitions aren't as smooth in this when I add them. :/

EDIT: On a side note, and this won't affect these XML mockups, but I'll be switching to half-stroke lines in the next iteration. This is just something which should look amazing on HiDPI screens.

Kver wrote:I hope you don't mind if I experimented with your work.

Not at all. In fact, I just merged your changes (replacing tabs with spaces).

Kver wrote:On your work with the menu, I think the main issue was that you weren't using background-clip to let the rgba border take full effect. Here's what it looks like with a few minor tweaks:

Changing the corner radius from 6px to 3px isn't minor . The menu isn't a grouping widget anymore (but looks way better).

Kver wrote:Also, I'll go back to my SVGs. You just make fun things to play with, and I'd like to see you try to get the full interaction model in there. On thing though; I don't know if it's Firefox not playing nice with XML, but it seems like border transitions aren't as smooth in this when I add them. :/

The SVGs will hopefully give me some more widgets to model, even if I still have some to work on .
My latest version includes JS code for focus handling (breaks browser shortcuts ; I'll work on that too). It is a good basis to model widgets more carefully. And I'll try to understand how to make work well (maybe I'll need to fall back to animations or even JS , because I could not make transitions on border-color).

One question: Is there a design for the focused sidebar ?

Please consider adding color scheme and transparency support for the Plasma and KWin themes! viewtopic.php?f=83&t=127252

louis94 wrote:

Kver wrote:I hope you don't mind if I experimented with your work.

Not at all. In fact, I just merged your changes (replacing tabs with spaces).

Kver wrote:On your work with the menu, I think the main issue was that you weren't using background-clip to let the rgba border take full effect. Here's what it looks like with a few minor tweaks:

Changing the corner radius from 6px to 3px isn't minor . The menu isn't a grouping widget anymore (but looks way better).

Kver wrote:Also, I'll go back to my SVGs. You just make fun things to play with, and I'd like to see you try to get the full interaction model in there. On thing though; I don't know if it's Firefox not playing nice with XML, but it seems like border transitions aren't as smooth in this when I add them. :/

The SVGs will hopefully give me some more widgets to model, even if I still have some to work on .
My latest version includes JS code for focus handling (breaks browser shortcuts ; I'll work on that too). It is a good basis to model widgets more carefully. And I'll try to understand how to make work well (maybe I'll need to fall back to animations or even JS , because I could not make transitions on border-color).

One question: Is there a design for the focused sidebar ?

Nice. Sorry for the tabs, I was just doing things quick and sloppy using my web design profile, which uses tabs.

The sidebar should follow the "flat button" school of highlighting. If there's anything not mocked up that you want to do, see what similar things are doing and extrapolate. Ideally we'll get things internally consistent enough that you could make up crazy widgets and just know how they should look and act.

MirceaKitsune wrote:Please consider adding color scheme and transparency support for the Plasma and KWin themes! viewtopic.php?f=83&t=127252

I like transparency effects too, and in (older) mockups I usually included them because it's my personal preference. I don't know if it fits this as a project (because I don't want to overscope), but if I get the chance to ninja-in a couple sliders for transparency options I'll give it a shot.

Heiko Tietze wrote:I'd appreciate if Breeze Dark get some love.

I second that. It seems that the dark version is treated as some afterthought at the moment, the issue Heiko mentioned being one example, others are for example issues with inheritance of icons in breeze dark, or that while there is a breeze transparent theme, there is no dark equivalent. I'd comment directly at opendesktop.org, but they blacklist hotmail addresses and I refuse to use my personal email to register an account for a most likely one-time use.

It would be nice to have full feature parity between the light and dark in the future.

Soukyuu wrote:

Heiko Tietze wrote:I'd appreciate if Breeze Dark get some love.

I second that. It seems that the dark version is treated as some afterthought at the moment, the issue Heiko mentioned being one example, others are for example issues with inheritance of icons in breeze dark, or that while there is a breeze transparent theme, there is no dark equivalent. I'd comment directly at opendesktop.org, but they blacklist hotmail addresses and I refuse to use my personal email to register an account for a most likely one-time use.

It would be nice to have full feature parity between the light and dark in the future.

(that moment when you have a dozen bullet points written and you accidentally hit one of the stupid side navigation buttons on your mouse while moving to hit "submit")

At this step I'm just trying to get the general widget style in order, once we know what the widgets look like I'm planning on making sure 3 palettes look good: Light, Dark, and Wonton Soup. Wonton soup is there because it's very neutral with low contrast. When these 3 look good across those 3 schemes, the rest should also look pretty decent without needing to draw them up.

Onto the widgets themselves, I've done the HiDPI design. I literally re-drew almost everything, so there's a huge number of subtle changes, but I'll try to outline the main ones. To see the best quality, you should download the full DPI version. On the whole DPI, I'm going to start referring to the pixels when it's in full resolution (180dpi) - so when I say 2px now, that's going to be 1px in the "preview" in this post. So halve every pixel I talk about the 90dpi thumbnail.


(Click to enlarge) | (Click here for source SVG)

• The entire thing is a little more organised.
• There are now separate states for focus and hover. Additionally, "checked" or "toggled" states have been made more consistent.
• The toggled state has been applied to the sidebar. The sidebar highlight is no longer attached to the line on the right (in lieu of the "improve sidebar" discussion) so it doesn't look funny when a scrollbar must be added.
• All widgets have outlines at 1px. This is in addition to any highlights, though the outlines fade out a bit so they don't overwhelm highlights. In the hover state the highlight is 2px. In the focus state the highlight is 4px.
• Outlines have been reduced to 1px (previous designs were 2px at 180dpi). Outline opacity has been roughly doubled. This makes things super-crisp at hiDPI, and still looks (mostly) the same at standard DPI.
• As of this design, blue highlights would only appear to indicate value (in the bars/dials/checkboxes) or interaction states (in outlines).
• All lines have been (roughly) doubled in contrast; at 90dpi this should look roughly the same, but at 180dpi this looks crisper and more defined.
• The menu now shows several more states, and has the design cues from the earlier discussion.
• Two animated progress bars have been added; I personally prefer the striped variant which is closer to the existing design.
• There are now 3 tab designs; traditional, floating, and kate-styles. As a special note, we can easily use two distinct styles of tab; one for document mode tabs, and the other for framed tabwidgets.
• Gradients have been removed from button widgets. Gradients have been replaced in input widgets in exchange for proper shadows.
• Removed some cruft.
• Shadows have been adjusted according to the discussion; widgets now have a short shallow shadow, menus have a larger and deeper shadow, and (not shown in the image) windows would have the deepest, largest shadows.
• There is one universal corner radius.

On a styleistic decision, I think any document-mode tabs could be the Kate style, and then we can use one of the other designs for tabwidgets; e.g. floating tabs.

This update was brought to you by COFFEE!

@Kver,
impressive work !
To be honest, I am not sure whether you can call it a "polish". Looks more like a rewrite to me.
Still, I have two concerns which I'd deem important:

The whole mokeup uses a single color for hover and focus (I guess that would be QPalette::Highlight).
Now, kde palette (and color schemes) have two different colors for hover and focus, that depending on the scheme, may or may not be the same.
(in the current breeze palette, they are not the same).

Also: (and this is only a personal oppinion), 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 oppinion). In fact, from the begining, 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)

In any case, using one pixel for hover and 2 for focus poses a serious issue imho:
for many widgets (but not all), mouse-over takes precedence over focus. This is the case for buttons, checkboxes, items in lists, scrollbars, etc.
So that with the design you propose, every time you will hover in and out of a focused widget you will see its outline "jump" from 2 pixel -> 1 pixel -> 2 pixel. Won't that feel weird ? Did you try it on QML ? I personally find the solution where two slightly different colors are used and the outline is unchanged much more elegant.

The alternative would be to make focus always take precedence on hover (as is the case now for input widgets), but I am sure many users will not be used to that. (the hover precedence is used to indicate that, whether a widget has focus or not, if you press it, *something* will happen).

Feedback welcome

schnelle wrote:Sorry if this thread is wrong place to report these Breeze issues.

Breeze is flat. Very flat. And yet this thingy is 3D glossy looking:


This part of plasma theme appears Air styled on every plasma theme:

Both issues are fixed in Plasma 5.4

But I found one new issue. Circle on the slider in new sound widget does not show correctly 100%:

Kver wrote:

Soukyuu wrote:

Heiko Tietze wrote:I'd appreciate if Breeze Dark get some love.

I second that. It seems that the dark version is treated as some afterthought at the moment, the issue Heiko mentioned being one example, others are for example issues with inheritance of icons in breeze dark, or that while there is a breeze transparent theme, there is no dark equivalent. I'd comment directly at opendesktop.org, but they blacklist hotmail addresses and I refuse to use my personal email to register an account for a most likely one-time use.

It would be nice to have full feature parity between the light and dark in the future.

(that moment when you have a dozen bullet points written and you accidentally hit one of the stupid side navigation buttons on your mouse while moving to hit "submit")

At this step I'm just trying to get the general widget style in order, once we know what the widgets look like I'm planning on making sure 3 palettes look good: Light, Dark, and Wonton Soup. Wonton soup is there because it's very neutral with low contrast. When these 3 look good across those 3 schemes, the rest should also look pretty decent without needing to draw them up.

So this one is more about the widgets and not icons/workspace theme?

hugo.pereira@free.fr wrote: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 oppinion). In fact, from the begining, 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)

I agree, the 2px seem too "fat" to me. It would be better to use a different color instead of increasing outline width, imho.

hugo.pereira@free.fr wrote:@Kver,
impressive work !
To be honest, I am not sure whether you can call it a "polish". Looks more like a rewrite to me.
Still, I have two concerns which I'd deem important:

Hahah, true enough. At least a heavy modification of the current version. Either way, I have no problem putting muscle into this.

hugo.pereira@free.fr wrote:The whole mokeup uses a single color for hover and focus (I guess that would be QPalette::Highlight).
Now, kde palette (and color schemes) have two different colors for hover and focus, that depending on the scheme, may or may not be the same.
(in the current breeze palette, they are not the same).

I did not know they were actually stored as two separate colours, I thought they were just a mix or a brightening. That makes sense though, and I'll make those adjustments in the next round.

hugo.pereira@free.fr wrote:Also: (and this is only a personal oppinion), 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 oppinion). In fact, from the begining, 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)

<opinion>

Just on an opinion level I'd say the opposite. When I see the pale blue fill on a grey window with no outline it bleeds into the background and looks muddy. The 2px highlight is definitely more bold, but I consider that a good thing for usability purposes, bold is good when used smartly. You can have a heavy design, a light design, and a design which uses both as appropriate; I don't want to jump onto the trendy "make everything thin/light" bandwagon because no/thin lines are "cool" on the mobile and Mac scenes... I want Breeze on the usability/consistency wagon. If the 2px effect were over-applied (like the quantity seen on the specimen sheet) it would be a bit much, but in real-world usage only one or two elements on screen having this effect won't "chub up" breeze.

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.

</opinion>

I'll throw some solutions out in a second.

hugo.pereira@free.fr wrote:In any case, using one pixel for hover and 2 for focus poses a serious issue imho:
for many widgets (but not all), mouse-over takes precedence over focus. This is the case for buttons, checkboxes, items in lists, scrollbars, etc.
So that with the design you propose, every time you will hover in and out of a focused widget you will see its outline "jump" from 2 pixel -> 1 pixel -> 2 pixel. Won't that feel weird ? Did you try it on QML ? I personally find the solution where two slightly different colors are used and the outline is unchanged much more elegant.

The alternative would be to make focus always take precedence on hover (as is the case now for input widgets), but I am sure many users will not be used to that. (the hover precedence is used to indicate that, whether a widget has focus or not, if you press it, *something* will happen).

I did not realise this was the case. Perhaps with the :hover colour defined in the theme we could treat the colour and thickness separately. I like this because one doesn't override the other, as focus and hover are different states. I'm smitten with the idea of using two visibly different cues.

In this situation I'd have hover alter the colour, and have focus alter the thickness. Mostly this is because tabbing through an application can produce less predicable "jumps" between widgets, so the bolder effect will more easily draw the eye to what's in focus.

hugo.pereira@free.fr wrote:Feedback welcome

Alright, solutions time!

On fills and outline in general, as long as we keep sane outlines one way or the other fills shouldn't bleed the way they do now. It just means we'd have to be careful about how we apply them (E.g. a highlighted outline bleeding into a highlighted fill bleeding into a grey background). I still have deep concerns about the consistency we could apply with those fills, but as much as I'd *love* to play overlord and force my personal views onto the design, this is a community project.

Personal bias may be leaking in here, but my first thought is to keep going down this road and focus on smaller refinements. This is mostly because we have some people who said they like it, and assuming preference is split 50/50 for/against it I'd ideally like to avoid making too many design u-turns at this point since we've hit on something usable, internally consistent, and which can be applied to the wider desktop as a whole. I definitely want to apply highlights as a separate colour though as you mentioned.

The second is for me to mock up what it might look like with fills and the current lines, and another version with fills and just hairlines... TBH I'm less keen to put the work in since it means having 3 designs floating around, and this being an opinion issue I question is there will ever be a clear winner. And again I'm concerned that if we put too much focus on what looks good on an individual level, we might lose sight of the big picture.

The third - probably best solution - would be to skip mockups and put it in as an option. Since this change is more of a personal taste issue than a functionality issue, it makes sense to me to have a checkbox to enable fills, or a dropdown which lets users pick between lines/fills/both effects. In this same vein we might also want to provide gradient fills as an option for people to are allergic to "flat" design (as the current design offers gradients on buttons). I don't feel the need to take extra time doing mockups if this is the route we go.

Soukyuu wrote:So this one is more about the widgets and not icons/workspace theme?

Icons are out-of-scope for this one, since they're constantly improving and it's very difficult to make "broad-brush" improvements across thousands of individual icons.

Mostly this is about the widgets, window decorations, and workspace theme; though the current focus is widgets. There's a little more to be looked at in windecos, and I'd like to tackle the workspace theme after we nail down the widgets.

schnelle wrote:Both issues are fixed in Plasma 5.4

But I found one new issue. Circle on the slider in new sound widget does not show correctly 100%:

Right now I'd like to stick with broad-brush changes to widgets, windecos, and any tweaks to the desktop theme in this thread. That being said, I think this looks like a bug report-type issue, I'd hit bugs.kde.org for that one.