Window titlebars
Open, Needs TriagePublic

Description

Right now, the Breeze color scheme uses a color for the active titlebar that's different and very strongly contrasting with the rest of the window background color:

When the window becomes de-focused, the titlebar changes color:

The Breeze dark theme, on the other hand, matches the titlebar color to the rest of the window background color and does not change it when the window becomes de-focused:

This is inconsistent, and each one has a significant disadadvantage associated with it:

  • Breeze: Having the titlebar color differ from the window color kind of looks unattractive, and I think this is one of the things that makes people say that we should use GNOME-style headerbars
  • Breeze Dark: There's almost no visual difference between focused and de-focused windows

I'd like to propose the following changes:

  • Define a "Tools Area" at the top of the window that consists of the titlebar, menubar, and toolbar (or any combination thereof)
  • The entire Tools Area has the same background color, which is slightly darker than the normal Window Background color
  • Draw a single-pixel horizontal line separating the Tools Area from the window content beneath
  • When the window is inactive, desaturate or lighten the Tools Area's background, text, and icons, and reduce the size of the window shadow

The non-dark version would wind up looking a bit like this on Dolphin. Thanks to @manueljlin for the fantastic mockups:

And then when the window is inactive:

And here's generally how it would look with a window that has no menubar or toolbar, just a titlebar:

There are a very large number of changes, so older changes are hidden. Show Older Changes

What would this look like in a language that isn't LTR? Would it be better to maybe have it on the right side in that case?

mglb added a comment.Jun 15 2019, 11:49 AM

What would this look like in a language that isn't LTR? Would it be better to maybe have it on the right side in that case?

Buttons are movable by user, so it could expand on empty side, both for LTR and RTL.

Last week I had to install Windows (bad experience overall), and I took that as a chance to consider their choises on this matter. One thing that I noticed is that Windows is using its fluent (/transparent window) effect in many applications, and it's used as a way to help the user understand which one is the active window. When the window is no longer active, the window become opaque. I found it quite interesting to use:

(Settings is focused)

(Edge is focused)

I know adding transparency to Breeze windows is highly controversial, but I think that if it was done with a small area, small transparency value and only on active windows it could satisfy all users. Transparency is already used this way in Breeze defualt panel and widgets, and I don't see many complaints about it. My idea then was to add a slight transparency to the tool area only on focused applications. This would make Breeze feel more modern and help the user easily see which application is focused.

I tried to do some general-shape mockups of the idea. In the images, you can see focused windows on the top and unfocused windows on the bottom. From left to right, you can see current design, Nate's proposal, and my proposal with additional transparency:

(Using Ice Cold wallpaper)

(Using Kokkini wallpaper)

(Using colorful wallpaper)

What do you think? I will also try to add a bit of noise to the mock.

Is there a consensus that the titlebars are not liked enough by the users, possibly because they appear to waste too much space while looking empty?

If so, I want to suggest this: Make the menubar titlebar button expandable, so the menubar can be shown inside the titlebar.

Are you suggesting this in addition or replacement of Nate's idea of tools area with the same color?

Last week I had to install Windows (bad experience overall), and I took that as a chance to consider their choises on this matter. One thing that I noticed is that Windows is using its fluent (/transparent window) effect in many applications, and it's used as a way to help the user understand which one is the active window. When the window is no longer active, the window become opaque. I found it quite interesting to use:

Personally I hate it and think if anything the logic should be reversed: the transparency should appear for inactive windows, not active ones. Otherwise the window you're actually trying to work with has reduced contrast and more visual noise that go away once you use a different window. I find it really maddening whenever I have to use Windows.

The thing about all this transparency stuff is that it's a cyclical design trend of the type that I want to avoid if possible. Apple debuted a really garish transparency in macOS 10.0 (in 2000), and Microsoft copied it in Vista (2007). By that time, Apple had toned it down significantly. Microsoft eventually toned it down as well, arriving at the current cheap plastic acrylic look, by which time Apple had made virtually everything in iOS transparent and blurry. By now they've toned it down as well, while Microsoft is making everything acrylicy.

It goes around and around in a circle forever, with people wanting more, then less, then more, then less again. I don't really want us to get on that treadmill.

ngraham added a comment.EditedJun 17 2019, 1:35 PM

That came off sounding kind of harsh, sorry. I don't hate blurry transparency, and I think a little bit can work when applied selectively and tastefully. But it has to be subtle, and it can't be underneath text that you're trying to read or else readability can suffer. For an example with our own implementation, see https://bugs.kde.org/show_bug.cgi?id=397851

In my book, readability and usability always need to come first.

Is there a consensus that the titlebars are not liked enough by the users, possibly because they appear to waste too much space while looking empty?

If so, I want to suggest this: Make the menubar titlebar button expandable, so the menubar can be shown inside the titlebar.

Are you suggesting this in addition or replacement of Nate's idea of tools area with the same color?

More like an addition. I don’t yet have an idea how tool areas could work, and if they don’t work, it couldd be replacement.

And I like ndavis' menubar (M151). It would be a good addition, because it indirectly shows the width of the menubar, which is important to open a context menu.

That came off sounding kind of harsh, sorry.

Don't worry :-) but I do appreciate your clarification.

the transparency should appear for inactive windows, not active ones

I understand that, but I would not like it as opening a single window will not show any blurrytransparency anywhere, and when present it would be on windows you do not give any attention to. This means that it would not "feel" blurrytransparent (which you might like or not).

a little bit can work when applied selectively and tastefully

I think applying a bit of blurrytransparency (maybe with high opacity) to the tools area can be tasteful, as you say, without any problem regarding usability. Of course, opacity should be tweaked so that it's readable and usable over *any* background. I think the current opacity of the panels is a great example, as it conveys blurrytransparency without hurting usability at all (that I know of, obviously).

I don't really want us to get on that treadmill.

I understand that, but I think it is possible to get on a stable middlepoint with a very slight transparency and keeping usability. But if we do so, it should not be "hidden" to inactive windows only, in my opinion.

I will admit that everytime I say "I will just use a tinyyyy bit of transparency here" I always get carried away, and it happens just so often :-) I can provide a couple of mockups using more opacity.

niccolove added a comment.EditedJun 17 2019, 7:31 PM

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

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

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

cblack added a subscriber: cblack.Jun 18 2019, 2:00 AM

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.

pettke added a subscriber: pettke.Jun 19 2019, 1:24 PM

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.

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.

alex-l added a comment.EditedJun 22 2019, 4:48 PM

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)

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.

johan.boule added a subscriber: johan.boule.EditedJul 28 2019, 5:19 PM

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.

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:

mglb added a comment.Nov 12 2019, 3:45 AM

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.

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%.

hase added a subscriber: hase.Nov 12 2019, 4:43 PM
mglb added a comment.Nov 12 2019, 5:47 PM

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.


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

GB_2 added a comment.Nov 12 2019, 7:16 PM


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.

ngraham added a subscriber: mart.Nov 12 2019, 7:43 PM
In T10201#207996, @GB_2 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.

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.

joricke added a comment.EditedNov 12 2019, 10:29 PM

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.

This comment was removed by KonqiDragon.

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

This comment was removed by KonqiDragon.
mglb added a comment.Nov 16 2019, 8:45 PM

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

ndavis added a comment.EditedNov 16 2019, 9:54 PM

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.

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?

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

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?

ndavis added a comment.Dec 2 2019, 3:49 PM

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.

ndavis added a comment.Dec 2 2019, 9:31 PM

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!

ndavis added a comment.EditedDec 2 2019, 9:43 PM

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.

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.

ngraham updated the task description. (Show Details)Jan 30 2020, 8:20 PM
niccolove added a comment.EditedFeb 26 2020, 3:24 PM

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

OptionToolsareaWindowsView
A#e3e3e3#eff0f1#fcfcfc
B#eff0f1#fcfcfc#fcfcfc

A would look like this:


B would look like this:

After some daily usage, I kind of prefer B

paulm added a subscriber: paulm.Mar 3 2020, 12:00 AM

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.

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?

joricke removed a subscriber: joricke.Apr 17 2020, 5:10 AM
mart added a comment.Apr 21 2020, 12:36 PM

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
mart added a comment.Apr 23 2020, 9:19 AM

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
mart added a comment.Apr 27 2020, 3:34 PM

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.

mart added a comment.Apr 28 2020, 9:05 AM

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.