A few weeks ago during the Plasma Sprint David Edmonston kindly sat down with me, and showed me how to get and build from KDE repos, where I started hacking on windecos. Originally I was just supposed start with a minor tweak, but I wound up overhauling a huge portion of the decoration look-n-feel, and it's diverged too much to be considered the 'same' decoration. Hugo made the wise suggestion that I post the state of my windeco variant for discussion before we consider integrating anything.

So, here's what the deco looks like (using xx-large buttons so you can see them better), note the default button size is identical to the current 'close' button size.

(please note: this image is a little out-of-date, it will be replaced later today when I have my dev machine)

Aaand a video;

Note: play back at 1080p. Sorry for the fuzziness.

Here's the main changes:

• Buttons have been placed in rings, emblems have been redone.
• There's a scaling effect in the animations.
• Min/Max/Close buttons have stop-light colouring. Other buttons are blue.
• The divider has been adjusted.
• There's very fine details which are perfect for high-dpi displays.
• There's a subtle gradient.

I have a couple configuration options I want to add - but I haven't yet figured out how the config works; if I figure it out, I do plan to add the options necessary to recreate the current design. No guarantees. That being said, I'm going to try making a branch for others to take the deco for a spin, but it may be a while off until I figure out how to make/maintain one properly.

Now for the bad news;
Unfortunately, the draw code has diverged *a lot* as I've iterated on it the past weeks, so I don't believe we can pick-and-choose things to back-port so easily; we can't really say "keep the glyphs, ditch the rest" without significant effort. There's also code-level review as well that Hugo and others will need to make, so even if you like what you see - there's no guarantee it will be used anyway.

I think we need to know whether or not people like where this new branch went/is going, if it's wanted, and any changes. More importantly, if it is wanted, we also want to know *how* it should be added; should it outright replace the existing design? Should it be added as a separate theme entirely? Or should it be relegated to gethotnewstuff?

I prefer the original one, but I like this one too. Why not ship both?

I like the hover color but for standard the colors are an eye catcher, but should the window decoration should be in the focus.

Congratulations, it looks very nice and we can see that you put a lot of effort to make it extremely polished. Looking forward to you applying your attention to detail on other parts of Plasma which needs some visual love

That being said, I would prefer that only the close button is coloured, and not the others. Of course, you can keep the hover effect, but I find the colours too distracting. It looks ok with your wallpaper, but I am concerned it would not look as good with another wallpaper such as a photograph.

Also, are the colours hardcoded to look like Mac OS X, or does it change with the colour scheme ? Did you try with another colour scheme ?

Cool stuff Ken!

I can think of two options. The first one would be to try to integrate this into the existing design. The second one would be to ship this as an additional decoration called "Breeze Chroma" or something.

If we try to integrate it with the existing decoration, I think the circle outlines would look great on hover, but be completely hidden otherwise. I kinda still like the filled-in close button as a visual counterweight to the application icon on the other side of the window in the default button layout. So my personal preference would be to keep the close button filled-in. But I'm probably a touch biased.

If we go with the second option, I say ship it pretty much as you have it, cuz I think it looks great. It might allow us to be a lot more explorative design-wise without the burden of trying to please everyone. Then as we learn what works and what doesn't, we can use that knowledge to refine the default designs. For example, maybe the refinements for high-dpi displays and maybe even the glyphs could be proposed for the default deco.

Anyway cool stuff as usual Ken!

Looks cool, Kver! Another way to provide the counterweight that Alake brings up would be to make the circles around the icons smaller on all but the close emblem.

I like the idea very much, and it looks quite good already. What I would do (if at all possible) is only have the colors on hover. I find that the current version is a little distracting and christmas-treeish. Didn't you choose monochrome icons in applications so that they stay out of the way while you work? I think the same applies here.

Great work!

Sorry for the late reply; I'm a terrible person.

We had a VDG meeting today and on the docket included windecos... I think we have plan!

For 5.3 we'll just submit a few smaller patches to the existing decoration; import glyphs and some minor detailing work. We won't try to add the crazy buttons or anything. We'll ship the new design as "Chroma", an alternate decoration.

After that I'll have some extra time to work on Chroma and add cool options / really refine the design. In addition to new stuff I'll also be adding configuration options which will let Chroma imitate Breeze with the right settings. This will probably be a 5.4 thing.

Once Chroma can fully imitate Breeze and people have had a chance to play with it, we'll poll the forums for what everyone wants the configuration to be - and we'll re-submit Chroma to once again become the default decoration. Hopefully, if all goes as planned, in 5.5 both decos will become one again.

We will take this cake... AND EAT IT!

Personally, I find them very beautiful, perhaps even more than the actual decoration, also I really like the idea of small splashes of color here and there, in the middle of the monochrome stile.Inoltre colors are combined well with the current default wallpaper.
I like so much seems to have a bit more personality

Hi all,
First, many thanks Kver for the update proposal, the post on the forum and the extra polishing you have put on the decoration, since the original review request.
I dump here the few comments that I had at the time and remain valid today, mostly for discussion.
I can post some of my personnal comments here (and copy there when the thread exist)

- Personally, I find the colors too distracting, especially when compared to the all sober breeze icon theme, and I fill I end up paying more attention to the decoration buttons that to the application's toolbar (which I believe is the opposite to what we would like to achieve)

- I fail to see the rationale behind the button coloring. I understand there is some sort of 'traffic light' metaphor, but then, why would minimize be more "orange" than say "unpin", or "keep below", or "un-maximize". Likewise, why would maximize be more "green" than say "pin", or "keep above".

- I fail to see the added value of the circles around the buttons, especially when there is already a nice mouse-over effect. To me, it is equivalent to adding a frame around every single toolbutton in a toolbar, around the icon. No objection to having it on mouse-over (or as a full paint as in the video), since this is actually more consistent with toolbuttons mouse-over

- On the redesign of the buttons, I'm overall happy with them.
I like the "pin" button, but I feel it is somewhat too "realistic" with respect again to the simplified breeze-icon theme.

- The same buttons are also used in the widget style, for dock manipulations (see: dolphin -> unlock panels, as well as kdevelop), and MDI windows (see oxygen-demo5, mdi window tab). So any change to the decoration should also come with a matching change to the widget style. Again, with the risk that they become too distractive there also (or we decide to use different buttons there, but lose consistency)

- on using positive/neutral etc colors for the buttons, please also have a look at review requests https://git.reviewboard.kde.org/r/122882/ and https://git.reviewboard.kde.org/r/122883/
they would be affected by the additional colors that this proposal need.

Finally on merging, as far as I understand, mostly the gliph rendering has changed. Right ? So all the rest (rounding, window background, size grip, animation infrastructure, caption centering, border sizes, button sizes, windows exceptions, etc ...) should be common to the current breeze code. Is that correct ? If yes, merging should not be too difficult. And we could provide two decorations with the same code base (that would make everybody's life easier).
If not, please detail (either here or by email) where the divergences actually are.
Something we should try to avoid is a lot of code duplication (that is: slightly different code, but that achieves the same thing).

Kver wrote:

• Buttons have been placed in rings, emblems have been redone.
• There's a scaling effect in the animations.
• Min/Max/Close buttons have stop-light colouring. Other buttons are blue.
• The divider has been adjusted.
• There's very fine details which are perfect for high-dpi displays.
• There's a subtle gradient.

Some more comments (again, for discussion, and for my own education):

by "the divider has been adjusted", you mean the slightly darker line above the blue one. Is that correct ? (you can notice it on the screenshot). If yes, although it look nice, I do not think it fits well with the current breeze theme design, as such shadows have been avoided so far, for the sake of flatness. (also: all shadows are bottom-right oriented, -meaning light comming from top left, whereas this one is at the top).
This IMHO matches much better the design choices that were made for oxygen (see e.g. tab bars), which, unless I'm mistaken, is also the style you use on the screenshot (correct?)

I love the idea of adding extra color to the buttons. Right now the really seem a bit plain in hopes to have users focus on the work they are doing rather than the buttons. I would probably use these however, the color intensity needs to be dialed down IMHO. Another option would be for them to light up only when there is mouseover. Like this

https://dribbble.com/shots/1413250-Butt ... offset=157

As part of the ongoing effort to improve the buttons, and somewhat orthogonal (and mergable) with Kver's proposal, I've played with the line width of the decoration glyphs, with the idea in mind to make them more in par with the icon theme.
See
Personally I'm quite happy with it.
The only button that does not fit so far is the "pin" icon (which is now too thick), and in fact, Kver's design would match better.
What do you think ?

(in particular Uri ?)

Hugo

hugo.pereira@free.fr wrote:As part of the ongoing effort to improve the buttons, and somewhat orthogonal (and mergable) with Kver's proposal, I've played with the line width of the decoration glyphs, with the idea in mind to make them more in par with the icon theme.
See http://wstaw.org/m/2015/03/18/plasma-desktopNi4078.png
Personally I'm quite happy with it.
The only button that does not fit so far is the "pin" icon (which is now too thick), and in fact, Kver's design would match better.
What do you think ?

(in particular Uri ?)

Hugo

I've been working on my own decoration in prep to break some things out; Now the glyphs are drawn in a separate function which accepts colour and 'outline mode' options (the idea being you draw the glyphs once as an outline, and again as a fill). About the main difference now is that they require QScale to be 2x, but I'm going to see if I can just have it draw 1:1 using the floating point draw functions instead to help sane things up.

If you want the function code I can just dump it in the thread or throw an email at'cha - I'd be eager to receive improvements if you wanted to collab on it.

Kver wrote:
I've been working on my own decoration in prep to break some things out; Now the glyphs are drawn in a separate function which accepts colour and 'outline mode' options (the idea being you draw the glyphs once as an outline, and again as a fill). About the main difference now is that they require QScale to be 2x, but I'm going to see if I can just have it draw 1:1 using the floating point draw functions instead to help sane things up.

If you want the function code I can just dump it in the thread or throw an email at'cha - I'd be eager to receive improvements if you wanted to collab on it.

The way I've dealt with scales so far (and various button sizes) in Breeze was using QPainter::setWindow. You can then specify any arbitrary canvas size to do you're painting (even 1024x1024 if you feel like to), use either float or ints, and then things are rescaled (automagically) to the initial (=real) size, by Qt.
Should be aware though that lines that fall on the grid in the 'viewport' coordinate (the one from setWindow) might not in the real window so that you can get anti-aliasing artifacts).