In T10201#189212, @niccolove wrote:

What do you think of: (opaque on the left, transparent on the right)

TBH, I can't tell the difference between both sides.

In T10201#189281, @ndavis wrote:

In T10201#189212, @niccolove wrote:

What do you think of: (opaque on the left, transparent on the right)

-snip-

TBH, I can't tell the difference between both sides.

It's subtle, but it looks a bit nicer. I feel like a bit less opacity would improve the effect.

One thing that should probably be considered is how to handle toolbars that are not at the top, but on the sides or the bottom of the window, as well as any combination of those. The possible cases seem to be quite tricky.

A particularly interesting case would be bottom toolbars, as a statusbar can be below it. Maybe it would be nice to have the status bar in the tools area color as well, in case bottom toolbars should be tinted. If technically possible, should the color and separation of the status bar change (if technically feasible at all) when toolbars are added to or removed from the bottom?

Currently, Kvantum is able to use different colors for toolbars based on their location, so that is feasable. I think it should get the tools area color only when it's put on the top, and leavingi everything else, including statusbar, with the normal lighter gray. When the toolbar is on the sides or on the bottom, it should be part of the window, and not of the tools area.

In T10201#189465, @niccolove wrote:

Currently, Kvantum is able to use different colors for toolbars based on their location, so that is feasable. I think it should get the tools area color only when it's put on the top, and leavingi everything else, including statusbar, with the normal lighter gray. When the toolbar is on the sides or on the bottom, it should be part of the window, and not of the tools area.

Yeah.

What do you think about inactive window title bar matching Plasma panels theme (90% opaque white by default with blur)?

Mockup also featuring the responsive title bar and a DWD widget:

It looks great, but we're moving in the direction of making the titlebar have the same color as the toolbar+menubar below it, which means it can't be as dark as depicted in your screenshot or else it's a ton of darkness that would be very distracting. While this issue would be slightly alleviated with DWD, DWD doesn't exist, likely never will, and even if it did, putting more controls in a combined titlebar/toolbar is a huge can of worms that in my opinion generates more problems than it solves, so I wouldn't want to do it. For my thoughts on the subject, see https://pointieststick.com/2018/12/18/on-headerbars/ and https://pointieststick.com/2019/03/06/more-on-headerbars-rebuttals/.

I'm not against the idea of making things slightly blurry and transparent under certain circumstances, but I would want to make sure it's subtle--like Plasma panels do, as you point out.

OK, but I don't think that changing Breeze theme for QtWidgets is a good idea to solve an issue with the title bar, only KDE/Qt applications using QtWidgets would benefit of this. And since then Breeze theme for QtWidgets and Breeze window decoration will only make sense if used together.

While DWD it's still not a thing it would be a real solution, not a theming hack.

BTW I made those mockups with a responsive title bar exactly to solve the issues of GNOME's headerbar. I don't see what are the disadvantages of making the title bar responsive, after all most UI parts are responsive today, but not title bars.

DWD is also very controversial and difficult to implement. Either way, this task is moving in a good direction, becoming more visually appealing for both sides, and way more feasable in the short term.
I also agree to use a subdle 90% opacity on the tools area as I stated before, but I'd prefer it to be applied either on all windows or only the active one. When applied only to inactive windows, it would be waay less noticeable and appealing.

The important thing is preserving the current ease in distinguishing active window from inactives (for all windows, not only Qt/KDE ones)

In T10201#189791, @alex-l wrote:

The important thing is preserving the current ease in distinguishing active window from inactives (for all windows, not only Qt/KDE ones)

Absolutely. It's a top priority. In addition, I think this will be improved for Breeze Light and Breeze dark, which currently have virtually no visual difference for active vs inactive windows.

In T10201#189792, @ngraham wrote:

In T10201#189791, @alex-l wrote:

The important thing is preserving the current ease in distinguishing active window from inactives (for all windows, not only Qt/KDE ones)

Absolutely. It's a top priority. In addition, I think this will be improved for Breeze Light and Breeze dark, which currently have virtually no visual difference for active vs inactive windows.

I don't understand. At the top of this page, it started by showing screenshots of Breeze Light where the active window titlebar is very clear.
This is a good thing, right?
So in the end, when the OP said "Breeze: Having the titlebar color differ from the window color kind of looks unattractive", aren't you all saying, no, this is a good thing?
(side note: "attractiveness" shouldn't be considered alone, as there are more long-term aspects to love or dislike, like usability)

Seems to me the consensus after all these comments are:
Light Breeze active window: good
Light Breeze inactive window: bad
Dark Breeze active window: bad
Dark Breeze inactive window: bad

Shouldn't there just be *distinguishable* colors for the active tiltebar, active border, inactive titlebar, inactive border, and content of window? The menus and toolbars should have their own distinct color(s) or it's gonna look super confusing. I know for a fact that it's not of any use to have the content of a window change when it's inactive, as long as the titlebar and the borders make it instant-clear which window is the active one. I've been using dead-simple windowing systems like this for decades and never even have had to question their usability: that is good. period. Comparing to that, the past fifteen years or so have seen the artificial creation of all sorts of usability problems, that I attribute to having too many technical possibilities and a too-strong desire from the programmers to push brand new GPU FX onto the face of the users like if those were still kids in the 80's and 90's astonished by the awesomeness of each new hardware doubling the color-count, and also a will do be the inventor of something new, no matter if it's good or bad, as long as it's new. These usability errors, are very slowly being "fixed", i.e. ideas killed one after the other. The end users probably have the lead here, as they for the most part don't fancy graphics as much as the developers of desktop environments do, didn't put personal efforts into implementing them, and so were quicker to dismiss the bad ideas.

It may look like a capitulation to go back to what we already had 35 years ago, a time when a few brilliant people studied these concepts, with technical constraints imposing minimalism, and usage was flourishing with users not accustomed to anything like that. But there's nothing to be ashamed of. You people had to do, by yourself, that errant voyage through all kinds of esoteric graphics. Now that you're done, can you please come home, thanks.

In T10201#193268, @johan.boule wrote:

In T10201#189792, @ngraham wrote:

In T10201#189791, @alex-l wrote:

The important thing is preserving the current ease in distinguishing active window from inactives (for all windows, not only Qt/KDE ones)

Absolutely. It's a top priority. In addition, I think this will be improved for Breeze Light and Breeze dark, which currently have virtually no visual difference for active vs inactive windows.

I don't understand. At the top of this page, it started by showing screenshots of Breeze Light where the active window titlebar is very clear.
This is a good thing, right?
So in the end, when the OP said "Breeze: Having the titlebar color differ from the window color kind of looks unattractive", aren't you all saying, no, this is a good thing?
(side note: "attractiveness" shouldn't be considered alone, as there are more long-term aspects to love or dislike, like usability)

Seems to me the consensus after all these comments are:
Light Breeze active window: good
Light Breeze inactive window: bad
Dark Breeze active window: bad
Dark Breeze inactive window: bad

Shouldn't there just be *distinguishable* colors for the active tiltebar, active border, inactive titlebar, inactive border, and content of window? The menus and toolbars should have their own distinct color(s) or it's gonna look super confusing. I know for a fact that it's not of any use to have the content of a window change when it's inactive, as long as the titlebar and the borders make it instant-clear which window is the active one. I've been using dead-simple windowing systems like this for decades and never even have had to question their usability: that is good. period. Comparing to that, the past fifteen years or so have seen the artificial creation of all sorts of usability problems, that I attribute to having too many technical possibilities and a too-strong desire from the programmers to push brand new GPU FX onto the face of the users like if those were still kids in the 80's and 90's astonished by the awesomeness of each new hardware doubling the color-count, and also a will do be the inventor of something new, no matter if it's good or bad, as long as it's new. These usability errors, are very slowly being "fixed", i.e. ideas killed one after the other. The end users probably have the lead here, as they for the most part don't fancy graphics as much as the developers of desktop environments do, didn't put personal efforts into implementing them, and so were quicker to dismiss the bad ideas.

It may look like a capitulation to go back to what we already had 35 years ago, a time when a few brilliant people studied these concepts, with technical constraints imposing minimalism, and usage was flourishing with users not accustomed to anything like that. But there's nothing to be ashamed of. You people had to do, by yourself, that errant voyage through all kinds of esoteric graphics. Now that you're done, can you please come home, thanks.

Breeze Light as a system colorscheme is not the same as Breeze. It's confusing and I really wish it was only "Breeze Light" and "Breeze Dark" so that Breeze could be the name of the theme overall and not interchangeably the light icon theme, the mostly light colorscheme and the theme overall.

Here's an idea for what Breeze Dark could look like with titlebars/headers/toolbars using the same color:

Application Style

What about extending vertical lines?

In T10201#207899, @mglb wrote:

Application Style

What about extending vertical lines?

That would require CSDs. I don't actually think these vertical line separators look that good anyway, especially the ones that extend into the page header area

On the topic of titlebars and their colors: what is the general consensus of having applications be able to set their own colors for titlebars? This would allow developers to establish a more "in brand" visual appearance (see screenshot attached). I'm currently working on a window decoration that lets users set per-window settings for titlebars. If users want, it'll also draw a separator underneath the titlebar by using the titlebar color and then applying a .lighter(n) filter to it to dark it considerably. This makes for a very smooth and fitting insert which still lets the user decide on what color-scheme they would like to use. Even when the titlebar area is extended to include the toolbox like in this mockup https://phabricator.kde.org/T10201#186877 it'll still look gorgeous. Readability of the icons can be ensured by doing simple lightness checks on the background color and then applying either white or black icon sets. I'm already doing this for the text in the titlebar and the inactive window buttons.

what is the general consensus of having applications be able to set their own colors for titlebars?

No consensus but I don't think we should allow applications to "brand" themselves. They should use whatever color scheme the user has decided for them or the system. If the user set a color scheme for them, then sure, we already have some infrastructure for that in e.g. Kate, Krita. It is possible to set a different color scheme for the decoration but it must be an existing theme on disk, an application cannot set arbitrary colors.

I don't think we should allow applications to "brand" themselves

I guess applications that would want to do this would have to do CSD then? Which would, of course, be ignored by KWin in favor of user settings. Fair enough.

In T10201#207904, @broulik wrote:

what is the general consensus of having applications be able to set their own colors for titlebars?

No consensus but I don't think we should allow applications to "brand" themselves. They should use whatever color scheme the user has decided for them or the system. If the user set a color scheme for them, then sure, we already have some infrastructure for that in e.g. Kate, Krita. It is possible to set a different color scheme for the decoration but it must be an existing theme on disk, an application cannot set arbitrary colors.

Agreed 100%.

Why (assuming it would be possible to disable it)?
Example use case: there is optional feature in Konsole which randomly adjusts foreground and background colors in each session (hue and saturation; perceived lightness is kept constant). It helps with finding specific window/session, as it is easier to find window tinted to specific color than looking at content/title (when it is similar), especially when window is scaled down (present windows effect). It could be nice to extend this adjustment to whole window (and titlebar), of course with user consent.
We make titlebars blended with window for consistency, and because it looks nice. Does it make sense to prevent similar consistency with application which uses different colors (e.g. web browser)?

Mentioned app/titlebar theme changing feature technically allows for any color scheme file (e.g. dynamically created in /tmp), it's just limited by official API, so thats not something hard to introduce. With some additional work, we could even adjust custom color proposed by application depending on user needs (i.e. just change hue, not lightness, like Konsole does).

This custom color could also be used to tint entries on taskbar, e.g. to instantly let me know which "a-project (zsh) - Konsole" (or just icon) to click to get this window which I remember had slightly green background. But thats a thing for another task.

In T10201#207994, @pedrogomes1698 wrote:

Having the line separated from the titlebar separator would make it a bit better, if we were to stick to this overall look.

I love this!

I don't think it's ideal but it's imo a improvement.

In T10201#207996, @GB_2 wrote:

In T10201#207994, @pedrogomes1698 wrote:

Having the line separated from the titlebar separator would make it a bit better, if we were to stick to this overall look.

I love this!

Yep, that's another TODO in Kirigami. IIRC it actually used to look like this but the feature was dropped due to an issue of excessive code complication. Maybe it can be brought back in a more maintainable way. @mart probably remembers the details.

Last idea that I'll just throw in here, maybe something on these lines would be neat.

I'm not sure the redundancy of information is a good thing, to be honest.

In the layout you're displaying, there's 5 mentions of "Application Style". Three of those mentions actually don't mean just the application style but include the window decorations as well. How about renaming the application style "container" to something like "window theme", which would meet the "global theme" in wording to add some consistency to the naming conventions.

Attached image file is my crude attempt at modifying your idea.

In T10201#208006, @joricke wrote:

I'm not sure the redundancy of information is a good thing, to be honest.

In the layout you're displaying, there's 5 mentions of "Application Style". Three of those mentions actually don't mean just the application style but include the window decorations as well. How about renaming the application style "container" to something like "window theme", which would meet the "global theme" in wording to add some consistency to the naming conventions.

Attached image file is my crude attempt at modifying your idea.

Keep in mind how it looks the window is smaller like this.

Yes, I'm aware of that, but even on that screen there's a mention of "Application Style" that implies the decoration of the entire window. It's just a mass of redundancy and confusing naming all over again. Can we not declutter this? And coming back to a discussion on the evolution of breeze: dial back the usage of styled frames?

I think that the highlighting is guidance enough to let the user know what setting they are currently tweaking. The labeling on the "back" button should also imply where the user is going to go back to when they click it to connect the "<" icon and label to the general action that is happening when this is clicked.

You made the redundancy worse again. Why waste space on the titlebar and make it larger again? Why add the "Application Style" font?

If so, Kirigami can be modified to work as needed.

In T10201#208006, @joricke wrote:

I'm not sure the redundancy of information is a good thing, to be honest.

In the layout you're displaying, there's 5 mentions of "Application Style". Three of those mentions actually don't mean just the application style but include the window decorations as well. How about renaming the application style "container" to something like "window theme", which would meet the "global theme" in wording to add some consistency to the naming conventions.

Attached image file is my crude attempt at modifying your idea.

I agree, the amount of times we display just the title of the active KCM in SySe is pretty insane, although one of those in my mockup is actually the name of the Application Style subcategory.

In T10201#208569, @ndavis wrote:

one of those in my mockup is actually the name of the Application Style subcategory.

True. But see how misleading using the same name for a category and an item is?

In T10201#208584, @joricke wrote:

In T10201#208569, @ndavis wrote:

one of those in my mockup is actually the name of the Application Style subcategory.

True. But see how misleading using the same name for a category and an item is?

I agree, the KCM should really be KDE/Qt Application Style to match the GNOME/GTK Application Style KCM

In T10201#208611, @ndavis wrote:

I agree, the KCM should really be KDE/Qt Application Style to match the GNOME/GTK Application Style KCM

Let's do it.

One question that came up in my mind: how would this new "combine area for titlebar and toolbar" affect themes that draw gradients on the titlebar?

In T10201#212407, @joricke wrote:

One question that came up in my mind: how would this new "combine area for titlebar and toolbar" affect themes that draw gradients on the titlebar?

Not at all. This would be implemented in the Breeze QStyle and people using those kinds of themes are already using a 3rd party QStyle.

Oh okay, so if I were to make a theme and would like to create a gradient that extends all the way from the top of the window to the bottom of the toolbar I'd essentially have to create a decoration and a qstyle and use the two to give the impression of a continuus gradient?

quite probably, for example, KvGnome does that

I haven't dug too deep into KFrameworks stuff, but is the decoration able to detect if the QStyle has to render a toolbar? I'm asking because on macOS for example the gradient is always the same, just more or less stretched depending on the size of the titlebar. This creates a very consistent look over all. This could also be used to draw or hide a titlebar seperator depending on wether or not a toolbar will be drawn in the window.

In T10201#212443, @joricke wrote:

I haven't dug too deep into KFrameworks stuff, but is the decoration able to detect if the QStyle has to render a toolbar? I'm asking because on macOS for example the gradient is always the same, just more or less stretched depending on the size of the titlebar. This creates a very consistent look over all. This could also be used to draw or hide a titlebar seperator depending on wether or not a toolbar will be drawn in the window.

I'm not quite sure, but if you have a QStyle and KDecoration that share code (both use C++), I don't see why you couldn't share data from the QStyle with the KDecoration. That's assuming you are using KDecoration to make the window decorations and that's different from making a window decoration that can detect this behavior from any QStyle.

The Aurorae engine is a more popular and easy but limited way to make custom window decorations. I don't think it would be able to do what you're talking about.

We don't have as much control over how Plasma can look as Apple does with MacOS, so we have to design the default QStyle and window decorations in a way that will allow them to look good together and with other combinations (e.g., Kvantum + Breeze decorations or Windows style Aurorae theme + Breeze QStyle).

The easiest way to make the toolbar and titlebar match is to just make the toolbar use the titlebar colors from the colorscheme.

The Aurorae engine is a more popular and easy but limited way to make custom window decorations. I don't think it would be able to do what you're talking about.

I didn't mean to ask for a solution using Aurorae. I'm currently working on a decoration and QStyle set which is based on a fork of Breeze, so it's good to know I can pass information from one to the other. Helps me out a ton for some fun ideas.
Thanks!

In T10201#212472, @joricke wrote:

The Aurorae engine is a more popular and easy but limited way to make custom window decorations. I don't think it would be able to do what you're talking about.

I didn't mean to ask for a solution using Aurorae. I'm currently working on a decoration and QStyle set which is based on a fork of Breeze, so it's good to know I can pass information from one to the other. Helps me out a ton for some fun ideas.
Thanks!

You may need to write the code to pass the information and it may not necessarily be a matter of passing the information at runtime, but just including a source file that contains the information. It may be easier if they're both in the same repo.

In T10201#187705, @alex-l wrote:

May I suggest to change title bar size from medium to little? I'm on a 169 DPI screen (very high for desktop without UI scaling) and it's still very usable

As someone who has slight motor skill issues related to a stay in the ICU (and nearly dying) 3 years ago, I will say that the default title bar size should remain. Note also that the second screenshot looks rather cramped in the second screenshot on my 4K monitor. Granted UI scaling will help with this, but we are beginning to see 8k monitors, so things need to be balanced.

Some general thoughts:

• Rounded corners make the windows look very attractive. Too many websites/operating systems have been going with flat, monotone, square designs for their UI elements. While I don't think KDE should go overboard with gradients, rounded stuff, etc. Having subtle rounded corners on the window combined with subtle shadows really makes KDE stand out and is very attractive.
• I find the neutral gray color to be much more visually pleasing than the current color schemes.
• The Window decoration icon choice has always been puzzling to me. I sort of get using ^ for maximize and the opposite for minimize, however the diamond for the restore icon is a very odd choice. Most UIs i've used use the windows style minimize/maximize icons: line at bottom of icon to indicate minimize, square with thick top line to indicate maximize, and 2 different squares with thick lines top lines (or two squares) overlayed to indicate restore. Those squares with thick top lines represent the window and titlebar. I know this probably won't change, but I figured I'd bring it up anyway :). Also the help 'question mark looks a bit big and the background circle around close really is not needed IMO.

Outside of that, the whole header bar look/feel looks very elegant, especially since KDE doesn't need to even implement a header bar.

Regarding the colorscheme to use; I was recently trying out a couple of options:

A would look like this:

After some daily usage, I kind of prefer B

I don't think the current Plasma 5 titlebar looks ugly at all (well, except for the confusing Windows 3-style buttons, but that is a different story which I have a proposal for here (update to that coming)). To me, rather the proposed changes to the titlebar here make the windows look rather bland and dull. I don't see any reason why usability should be sacrificed like this for the sake of a fashion change. It is much more important to make the active window stand out, and also make it clear that there is an area which you can definitely drag.

In T10201#208008, @joricke wrote:

Yes, I'm aware of that, but even on that screen there's a mention of "Application Style" that implies the decoration of the entire window. It's just a mass of redundancy and confusing naming all over again. Can we not declutter this? And coming back to a discussion on the evolution of breeze: dial back the usage of styled frames?

I think that the highlighting is guidance enough to let the user know what setting they are currently tweaking. The labeling on the "back" button should also imply where the user is going to go back to when they click it to connect the "<" icon and label to the general action that is happening when this is clicked.

Ping-a-ding... any chance that we can look at this idea once more now Application Style KCMs are merged into one KCM?

Note: the kirigami patch implementing it was wrong, caused crashes and has been reverted.
the way this thing wants to be implemented needs to have 2 parts:

1. a new titlebar (or whatevergood semantic name for it) needs to be added to KColorScheme https://api.kde.org/frameworks/kconfigwidgets/html/classKColorScheme.html#a49fb44861670c838d940c70205318136 so then is easy for qwidget applications to use it (and is also the proper place the kirigami desktop theme should take it from)
2. in Kirigami, also use a colorset just like all the other colorsets, which in the desktop theme would take it from KColorScheme just like all the other things
3. (the half-deprecated) Plasma::Theme should get it too for compatibility

looking a bit at the problem and at how KColorScheme works, my proposal is the following:

• have a new group in KColorScheme, independent from window titlebar colors, called ToolsArea, HeaderBar or something like that.
• Breeze QStyle would use that kcolorscheme group for the top titlebar only
• Apps can use it for extra things if they want
• the breeze decoration, would use that new group, and *not* the [WM] group, which doesn't have enough colors for actual widgets to work into (just like oxygen which doesn't use those colors)
• if there is a setting in the decoration or somewhere else, the actual decoration would use this group only there.
• Ideally, KDecoration (and somewhere in the styles?) could have some api to advertise if this fusion of titlebar/toolbar is supported by the moving parts

D29232 tries to add a new color group, with experimental support for a cmpletely speared set for the "inactive" case

Thanks! Keep in mind that we want this to apply to 3rd-party apps as much as possible as well. Even for apps that only get a KWin-drawn SSD titlebar, we still want that titlebar to have the same background color as the whole Tools Area on a KDE app.

is a final color set decided for this?
https://phabricator.kde.org/D29232#inline-167074

In T10201#228340, @ngraham wrote:

Thanks! Keep in mind that we want this to apply to 3rd-party apps as much as possible as well. Even for apps that only get a KWin-drawn SSD titlebar, we still want that titlebar to have the same background color as the whole Tools Area on a KDE app.

yeah, the breeze window decoration would then use those colors instead, maybe falling back to the ild WM group for old colorschemes but use those if available (i guess same for aurorae, oxygen already just ignores the WM colors)

In T10201#228393, @mart wrote:

is a final color set decided for this?
https://phabricator.kde.org/D29232#inline-167074

Almost. We're playing around with the background colors in D28317. Except for the Background and Alternate Background colors, I think the Header color set should be the same as the Window color set.

Hi! I can’t seem to find any branch in D27669 that allows me to turn off the border below the tools area. It looks like the line is hardcoded to be interpolated between text color and background color which would make it impossible to turn off. Am I missing something?

I currently have “draw separator between titlebar and window” unticked and would like to be able to uncheck its equivalent in the future too.

Ah, so I did miss something in the code! So I just have to set the titlebar color to “unset” and the border vanishes? Nice!