There are some changes with respect to the QML above, such as:- for checkboxes, radiobuttons and pushbuttons, I've implemented shadows that would come from "above" rather than from "top-left" (since it is more consistent with what we have for the decorations, and because I see no reason to prefer top-left over top-right)- for most hover and focus effects, the QML uses only the QPalette::Highlight color. Now, KDE's KPalette provides separate Hover and Focus colors, so I've used them instead- for some widgets I had to improvise. This includes: menubar and menu hovered/focused/pressed items; QDials; toolbar handles (I'm not happy with this one)

Also, most of the hover and focus effects are 'smoothly' animated as they were in oxygen.In fact most of the code comes from oxygen, though for now I've preferred making a deep copy than actually sharing the code via libraries.

Ultimately I would like to:- push this to some official repository (where should that be ? kde/workspace/breeze/kstyle ?)- make it the 'official' kf5 style (instead of the current QtCurve settings)- have feedback- iron out the remaining issues

Among the things that are most notably missing are: a configuration ui (!)(though I foresee less things to be configurable than with oxygen)

Hugo, you da man!I had already settled with the idea that it might take a couple more releases until we get a "proper" Breeze widget style, and now you come along and "just do it"™ It looks fabulous!

The only thing I noticed that looks a bit alien within the new theme is the clear button for text fields. That's still the original Oxygen one, isn't it? I guess it's mostly the gradient that doesn't seem to fit with the new theme. Could it be "flattened" maybe?

One question: What do you mean by "toolbar handles"? Are those visible in any of the screenshots?

Hi Colomar,For the clear button, the thing that strikes most is that it is misplaced IMO (missing a right side margin). This is likly due to the widget itself and not something the style has direct access to I think, though I will double check.For the toolbar handles, no they are not in the sceenshot. This is what you get when you "unlock toolbars" in any kde applications, in order to be able to move them around.Right now they look like this:http://wstaw.org/m/2014/08/11/plasma-desktopDA1788.png

Thanks for posting here about your progress Hugo. As I mentioned in my email, superb work! I'm completely bowled over by your progress.

hugo wrote:There are some changes with respect to the QML above, such as:- for checkboxes, radiobuttons and pushbuttons, I've implemented shadows that would come from "above" rather than from "top-left" (since it is more consistent with what we have for the decorations, and because I see no reason to prefer top-left over top-right)

That's probably a reasonable conclusion given that we perhaps didn't communicate this very well. The lighting model for all of the breeze design is actually, consciously top-left. The breeze window decoration the C++ version of which is currently being implemented from the QML version, uses a top left model as well. :-)

- for most hover and focus effects, the QML uses only the QPalette::Highlight color. Now, KDE's KPalette provides separate Hover and Focus colors, so I've used them instead

Makes sense to me!

- for some widgets I had to improvise. This includes: menubar and menu hovered/focused/pressed items; QDials; toolbar handles (I'm not happy with this one)

Also, most of the hover and focus effects are 'smoothly' animated as they were in oxygen.In fact most of the code comes from oxygen, though for now I've preferred making a deep copy than actually sharing the code via libraries.

Makes sense to me. We can work out any remaining details as we go. If there's a visual that's not so clear what the best solution should be just post here on the forums and we'll knock out a design for it.

We (the VDG) will likely need to revisit the progress bar design since we didn't account for the % label which currently moves it off-center. We'll work on that and deliver an updated design that considers that. For now, it's fine as is.

I know this'll seem like a nit-pick, but is it possible to have the ends of the slider and the progress bar have a similar margin so they share the same alignment line (http://wstaw.org/m/2014/08/11/oxygen-demo2.png)? I completely understand why they look that way right now functionally, but this tweak would be primarily for visual not functional reasons. I'll need update the QtQuick implementation as well.

There may be one or two other very minor things, but I'll wait till you find a home for this and start ironing out any outstanding issues.

hugo.pereira@free.fr wrote:Hi Colomar,For the clear button, the thing that strikes most is that it is misplaced IMO (missing a right side margin). This is likly due to the widget itself and not something the style has direct access to I think, though I will double check.For the toolbar handles, no they are not in the sceenshot. This is what you get when you "unlock toolbars" in any kde applications, in order to be able to move them around.Right now they look like this:http://wstaw.org/m/2014/08/11/plasma-desktopDA1788.png

hugo.pereira@free.fr wrote:Hi Colomar,For the clear button, the thing that strikes most is that it is misplaced IMO (missing a right side margin). This is likly due to the widget itself and not something the style has direct access to I think, though I will double check.For the toolbar handles, no they are not in the sceenshot. This is what you get when you "unlock toolbars" in any kde applications, in order to be able to move them around.Right now they look like this:http://wstaw.org/m/2014/08/11/plasma-desktopDA1788.png

Additionally to Andrew's points I'd like to know from you (and the others here) if it would be possible to have the highlight in the navigation panel on the left (I forgot the proper name ) not use rounded corners. I think the rounded corners look a bit strange when it's in this box.Other than that, I'm really impressed and glad about the work you've done!

Some feedback from my own tinkering with it.* Everything seems a little too big. I have a large monitor with high resolution and the tabs seems just massive to me.* Breeze hover color is too light. I can't see the scrollbar when I click and drag it to scroll.* Progress bar is too thin* Gradients are a little strong, I would prefer a flatter style found in the Qtcurve theme being shipped now* I miss the cool little animation that you would get when clicking buttons or checkboxes in the Breeze Style demo. It would make the button actually move down like it was responding to the pressure of the click. I would love to see that animation in the new theme.* Button padding is too little, they seem too cramped.

Additionally to Andrew's points I'd like to know from you (and the others here) if it would be possible to have the highlight in the navigation panel on the left (I forgot the proper name ) not use rounded corners. I think the rounded corners look a bit strange when it's in this box.Other than that, I'm really impressed and glad about the work you've done!

First of all: Really amazing work! Thank you, Hugo!

Now my concern is: In addition to rethinking the rounded corners of the highlight inside the box, we should think about getting rid of the box completely. (at least in this case, not sure if the theme can do that, or if it's an application thing)Most of the mockups, that have been done so far, are getting rid of the box (e.g. https://hanswchen.files.wordpress.com/2 ... erview.png, http://wstaw.org/m/2014/08/05/mockup_0.png).So: Which QWidget-class is the navigation box on the left? Would it make sense to generally remove the box for that class or is it needed at least sometimes? In case of the latter: Is there a class, for this kind of navigation widget or would it make sense to add one?

Anton wrote:Now my concern is: In addition to rethinking the rounded corners of the highlight inside the box, we should think about getting rid of the box completely. (at least in this case, not sure if the theme can do that, or if it's an application thing)Most of the mockups, that have been done so far, are getting rid of the box (e.g. https://hanswchen.files.wordpress.com/2 ... erview.png, http://wstaw.org/m/2014/08/05/mockup_0.png).So: Which QWidget-class is the navigation box on the left? Would it make sense to generally remove the box for that class or is it needed at least sometimes? In case of the latter: Is there a class, for this kind of navigation widget or would it make sense to add one?

Ah yes, you're right, removing the white background was also the general agreement on this thread about "sidebars": viewtopic.php?f=285&t=120006

Additionally to Andrew's points I'd like to know from you (and the others here) if it would be possible to have the highlight in the navigation panel on the left (I forgot the proper name ) not use rounded corners. I think the rounded corners look a bit strange when it's in this box.Other than that, I'm really impressed and glad about the work you've done!

First of all: Really amazing work! Thank you, Hugo!

Now my concern is: In addition to rethinking the rounded corners of the highlight inside the box, we should think about getting rid of the box completely. (at least in this case, not sure if the theme can do that, or if it's an application thing)Most of the mockups, that have been done so far, are getting rid of the box (e.g. https://hanswchen.files.wordpress.com/2 ... erview.png, http://wstaw.org/m/2014/08/05/mockup_0.png).So: Which QWidget-class is the navigation box on the left? Would it make sense to generally remove the box for that class or is it needed at least sometimes? In case of the latter: Is there a class, for this kind of navigation widget or would it make sense to add one?

In most applications, the said widget is a KPagedWidget (or something similar)To get the desired effect, it should be made flat, and transparent. Not a style thing, as far as I know.For Dolphin, though, its a different thing. It's 'simply' a QDockWidgetFor now I framed it, like TabWidgets are, with the same outline color.I can easily get rid of it, but then you will run into weird things when you 'unlock' panels there.In this case, you would get extra buttons, and a title bar, to indicate that you can 'move' and 'close' the panels, but actually no panel to which these move and close actions refer to. (so that the buttons look out of the blue)Possibly, one can 'frame' these only when 'unlocked', but I am not sure I have access to the information from the style

enoop wrote:Found a problem, if there are checkboxes in a list, the highlight fills in the check box, making it very difficult to tell if it is checked or not.https://imgur.com/km98Rln (Picture of the problem)

Agreed, its an issue. Will see what I can do. (need to detect checkboxes inside lists, and whether item is selected or not. Not sure how doable it is, sadly)

hugo wrote:There are some changes with respect to the QML above, such as:- for checkboxes, radiobuttons and pushbuttons, I've implemented shadows that would come from "above" rather than from "top-left" (since it is more consistent with what we have for the decorations, and because I see no reason to prefer top-left over top-right)

That's probably a reasonable conclusion given that we perhaps didn't communicate this very well. The lighting model for all of the breeze design is actually, consciously top-left. The breeze window decoration the C++ version of which is currently being implemented from the QML version, uses a top left model as well.

- for most hover and focus effects, the QML uses only the QPalette::Highlight color. Now, KDE's KPalette provides separate Hover and Focus colors, so I've used them instead

Makes sense to me!

- for some widgets I had to improvise. This includes: menubar and menu hovered/focused/pressed items; QDials; toolbar handles (I'm not happy with this one)

Also, most of the hover and focus effects are 'smoothly' animated as they were in oxygen.In fact most of the code comes from oxygen, though for now I've preferred making a deep copy than actually sharing the code via libraries.

Makes sense to me. We can work out any remaining details as we go. If there's a visual that's not so clear what the best solution should be just post here on the forums and we'll knock out a design for it.

We (the VDG) will likely need to revisit the progress bar design since we didn't account for the % label which currently moves it off-center. We'll work on that and deliver an updated design that considers that. For now, it's fine as is.

I know this'll seem like a nit-pick, but is it possible to have the ends of the slider and the progress bar have a similar margin so they share the same alignment line (http://wstaw.org/m/2014/08/11/oxygen-demo2.png)? I completely understand why they look that way right now functionally, but this tweak would be primarily for visual not functional reasons. I'll need update the QtQuick implementation as well.

There may be one or two other very minor things, but I'll wait till you find a home for this and start ironing out any outstanding issues.

Overall it looks fantastic!

Thanks again for all your hard work on this Hugo!

rounding: I have adjusted (was 0.5 too large). Looks much better now. This and some adjustment on the outline color

light source: I have changed to top-left, though I kept a (hidden) option to switch back to 'top' only.To be honest, I am still not convinced of the top-left model. First off, and only in my humble, biased opinion, I find it 'retro'. Most examples I see around (web pages, browser, etc.) Use a top model. Also: why left ? should it be top-right for right-to-left languages (Arabian) ? For left-handed people ? ... anyway: just food for thought.

box around header: you mean the title at the top of the screenshot ? Its a KTitleWidget. Yes I can remove the box.should the background go as well ? this would make it look pretty much like it was in oxygen (meaning: nothing is drawn), though people complained at that time (namely: the icon looks out of nowhere, and the text is Top aligned, which looks weird if no text). By default KTitleWidget appears frameless, but with a forced white background. So I have to either hack the frame around, or hack to force removal of the white background. All in all, I'd rather have this fixed in the KTitleWidget directly, and then remove my hacks.

progressbars: agreed, centering is broken. One possibility is to write the % text on the side rather than at the top (some built-in Qt style do that).

sliders vs progressbars: difficult. Would need to enlarge the slider (length of progress bar is aligned to other widgets). But then (I checked), when slider is at the limits, the progressbar still extends beyond the slider, by one pixel, as a consequence of the shadow around the slider. Which looks weird, since then you feel like you would like to drag the slider even more. I'll think more about it.