Hi,

I started working on a new window decoration API. I want to tackle three tasks with it:

1. New decoration API for KWin 5.1
2. A client-side decoration API for QML (I rather do it myself than have to fix it from KWin)
3. A deco API for QtWayland (same reason as with QML)

The new API comes with two additional features: an interactive theme previewer (I need that for developing) and a C++ implementation of the Breeze window decoration.

And the last item is the reason for opening this thread: I have questions Just now I implemented disabling of buttons and wondered how a disabled button should look like. Also I noticed that the read of the close button is hard coded - I guess it would be better to derive it from a color scheme color.

@ivan pointed out in another thread that grayed out objects are considered inactive so i would say that the disabled button should be desaturated with ~60% opacity.

EraX wrote:@ivan pointed out in another thread that grayed out objects are considered inactive so i would say that the disabled button should be desaturated with ~60% opacity.

that's a good idea. I just gave it a try on the close button: http://paste.opensuse.org/56248204

The "outer" window decoration is the QML deco, the inside deco is the C++ implementation I'm working on. This should show the difference in the close button.

Yes i think the distinction is pretty clear.
Maybe a silly question, but with the new decoration will the applications be finally allowed to place tabs or buttons there?

EraX wrote:Yes i think the distinction is pretty clear.
Maybe a silly question, but with the new decoration will the applications be finally allowed to place tabs or buttons there?

of course not. It's not a question of the decoration, the problem is coordination. As long as nobody contacts me with a concrete proposal on how to do this from application side it won't happen.

and another question: the keep above and keep below buttons are toggle buttons but don't follow the way other toggle buttons are done (on all desktops, shade, maximize). Keep above/below just change the background, while the others change the symbol. I think that's not consistent and would prefer having a changed icon for keep above/below, too. Any suggestions and thoughts on it?

EraX is on track, but I'd go with something more like 25% opacity for disabled buttons. It needs to be very clear that they are disabled so the user doesn't get the impression that the app has stopped responding.

Agreed with garthecho and EraX on the disabled button.

Regarding the close button hover and pressed color, I think just for the close button I think it's appropriate to have it always set to Danger Red on hover and pressed. Certain icons in the breeze icon theme that represent destructive actions have a similar color and is similarly invariant with the color scheme.

mgraesslin wrote:and another question: the keep above and keep below buttons are toggle buttons but don't follow the way other toggle buttons are done (on all desktops, shade, maximize). Keep above/below just change the background, while the others change the symbol. I think that's not consistent and would prefer having a changed icon for keep above/below, too. Any suggestions and thoughts on it?

My inclination is to go in the other direction actually. I'm honestly thinking there are already quite a few visual metaphors for the user to interpret for each window state. I'm thinking just one visual metaphor for each window state idea (all desktops, shade, max, keep above, etc.) paired with a simple on/off visual representing the current state (e.g. turn on background, inverting colors, etc.). We would need to revisit the button icon designs to make sure they're adequate when paired with a simple on/off state visual. But at least it would keep the proliferation of visual metaphors down a bit. Thoughts?

Hope this helps!

alake wrote:Agreed with garthecho and EraX on the disabled button.

Regarding the close button hover and pressed color, I think just for the close button I think it's appropriate to have it always set to Danger Red on hover and pressed. Certain icons in the breeze icon theme that represent destructive actions have a similar color and is similarly invariant with the color scheme.

I don't like hardcoded values, it makes the programmer in me scream I just checked for the Plastik decoration and that uses the NegativeText role of the color scheme for the close button. In case of the breeze color scheme that is #9c0e0e.

alake wrote:

mgraesslin wrote:and another question: the keep above and keep below buttons are toggle buttons but don't follow the way other toggle buttons are done (on all desktops, shade, maximize). Keep above/below just change the background, while the others change the symbol. I think that's not consistent and would prefer having a changed icon for keep above/below, too. Any suggestions and thoughts on it?

My inclination is to go in the other direction actually. I'm honestly thinking there are already quite a few visual metaphors for the user to interpret for each window state. I'm thinking just one visual metaphor for each window state idea (all desktops, shade, max, keep above, etc.) paired with a simple on/off visual representing the current state (e.g. turn on background, inverting colors, etc.). We would need to revisit the button icon designs to make sure they're adequate when paired with a simple on/off state visual. But at least it would keep the proliferation of visual metaphors down a bit. Thoughts?

Hope this helps!

That sounds fine, too. As long as I don't have to change the implementation again and again (hint we need someone whom I can pass the code to for the polishing). So far I didn't implement the pin for all desktops as that's too complex for my drawing skills.

There are a few more things I need As breeze will become the default decoration it needs to support window tabs. For that I need a kind of design (as I thought about EraX question: it should also be generic enough that we could implement in-app tabs in the window decoration).

The second request is about what I call "magic values". The elements are positioned with adding values to them. As the buttons should be fully scalable (for accessibility) it would be best if this is expressed by a multiplication. Anyway best would be a summary of all margins and how they should be. But that's also something which can be done once I pass it on.

mgraesslin wrote:I don't like hardcoded values, it makes the programmer in me scream I just checked for the Plastik decoration and that uses the NegativeText role of the color scheme for the close button. In case of the breeze color scheme that is #9c0e0e.

Haha! No worries. If there's place in the palette for something like a Warning role or a Caution role then that's fine I think... hold up... Ok, I just checked the KColorScheme class doc. Yes NegativeText (or maybe NegativeBackground?) seems like the right role. The breeze color schemes will need to be updated to set all those colors correctly. I have a task on my to do list to work with the community this cycle to flesh out a full color palette with shades of each of the existing primary and secondary colors. I'll update the breeze color scheme once that's done.

As long as I don't have to change the implementation again and again (hint we need someone whom I can pass the code to for the polishing). So far I didn't implement the pin for all desktops as that's too complex for my drawing skills.

If it's being done with QPainter and if no one else volunteers to do it then I'd be happy to do the polishing. As long as the button icon painting implementation is relatively isolated, I'm fine with making sure any design changes get in. Some refreshed button icon designs might be incoming for the 5.1 cycle anyway.

There are a few more things I need As breeze will become the default decoration it needs to support window tabs. For that I need a kind of design (as I thought about EraX question: it should also be generic enough that we could implement in-app tabs in the window decoration).

Maybe garthecho and EraX would be willing to help come up with a candidate design for the Breeze window tabs? Holler if you can.

The second request is about what I call "magic values". The elements are positioned with adding values to them. As the buttons should be fully scalable (for accessibility) it would be best if this is expressed by a multiplication. Anyway best would be a summary of all margins and how they should be. But that's also something which can be done once I pass it on.

Yes, indeed. I'll try to come up with a spacing and margin spec for all the button and titlebar visuals and post it here.

I'll try to come up with something tomorrow

Ok so here is what i came up with so far. Six variants.
https://dl.dropboxusercontent.com/u/633 ... c_tabs.png
#1 Active tab
#2 Hovered tab

Looks pretty cool. Personally I like the fourth one best. Could you try to also add a close button? It's something Oxygen used to have and from user feedback that was quite appreciated.

alake wrote:

As long as I don't have to change the implementation again and again (hint we need someone whom I can pass the code to for the polishing). So far I didn't implement the pin for all desktops as that's too complex for my drawing skills.

If it's being done with QPainter and if no one else volunteers to do it then I'd be happy to do the polishing. As long as the button icon painting implementation is relatively isolated, I'm fine with making sure any design changes get in. Some refreshed button icon designs might be incoming for the 5.1 cycle anyway.

Yeah it's just QPainter and extremely isolated. Each button is rendered by itself. I have some ideas for improved non-QPainter rendering (GL directly in case of KWin's OpenGL compositor) but that's for a later release.