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 (WARNING: crude mockups incoming)

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
ngraham updated the task description. (Show Details)Jun 10 2019, 2:45 PM

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


In general I think the UI elements throughout KDE software are too small, not too large (see also T9460). Making sure interactive controls are large enough to provide decent click targets is particularly important for people with limited motor skills, children, touchpad users, and touchscreen users. I think making titlebars smaller by default would impair those use cases. People who prefer a more compact appearance can already change the size themselves. :)

@ngraham After thinking better, I think you're right but I also think that such a large title bar contributes a lot to making users hate server-side decorations. I can't think of any solution apart from making it more useful with tabs like in the Plasma Sets mockup.

@ngraham After thinking better, I think you're right but I also think that such a large title bar contributes a lot to making users hate server-side decorations. I can't think of any solution apart from making it more useful with tabs like in the Plasma Sets mockup.

Maybe this is just a perception from the point of view of the icons. When looking at the two images, I don't see a perceptible change with the titlebar height, but I notice it with the icons. If the icons were consistently the same size and the titlebar a different height, would that be good?

mglb added a subscriber: mglb.Jun 11 2019, 3:20 PM

I would like my desktop to simply tolerate applications with different interfaces.pHow about a simple approach to preserve such interfaces: Count the number of toolbar rows, and only darken the toolbars if they are not more than 2 or 3 rows. Otherwise, only darken the menubar.

The problem with that is it will look broken and people will file bug reports about it.

Maybe per-app/per-window breeze configuration, like KWin's "Window Rules"?

Please consider that KDE apps with Breeze theme could run in a DE without KWin

Looks OK (I mean, app-side titlebar integration)

that not all the apps use Qt, KDE widgets and Breeze theme: KWin should make obvious for every app if its window is active or not.

I agree. I was using Breeze Dark color scheme, where disabled titlebar only has darker text. It's OK on a laptop, but on a setup with 3 vertical monitors it was not enough to spot which Konsole window has been activated with alt+tab.

Also I think that we should explore the possibility to have tabs like in my mockup "Plasma Sets": https://phabricator.kde.org/M128

Edit, mockup active vs inactive window:

https://kver.wordpress.com/2014/10/25/presenting-dwd-a-candidate-for-kde-window-decorations/

BTW. There were window tabs (not app controlled though) in KDE4, but nobody ported them.

one question, will the USER-CHOSEN color scheme for a window will be taken into account for the menu and the toolbar also ?
the following has been achieved with kvantum specifing the same color scheme (manually) with the kwin applied color scheme for a window

Non-toolbar window area has light gray color, right? Can you show e.g. Dolphin with "Places" panel? There can be a problem with symbolic icons.

Now, having Breeze (light) actually be light in its entirety could be another step in improving things. FWIW some of my experiments in achieving fluidity between the WM and the window revolved around a different solution - painting the controlbar in a dark color, same as the titlebar.

Is this just a mockup? If not, how different icon sets on a toolbar and rest of a window are handled?

In T10201#188085, @mglb wrote:

Maybe per-app/per-window breeze configuration, like KWin's "Window Rules"?

Unlikely to happen for the same reason there isn't per app kwin rules for CSD apps to have shadows.
Technically its posable but its a dirty hack that would have to be done on every app that isn't designed well.

In T10201#188085, @mglb wrote:

Now, having Breeze (light) actually be light in its entirety could be another step in improving things. FWIW some of my experiments in achieving fluidity between the WM and the window revolved around a different solution - painting the controlbar in a dark color, same as the titlebar.

Is this just a mockup? If not, how different icon sets on a toolbar and rest of a window are handled?

Just a mockup, that's why I could mix icons.

BTW. There were window tabs (not app controlled though) in KDE4, but nobody ported them.

AFAIK tabs were ported and are there in KWin but there isn't support in Breeze window decoration, that is what we are discussing here, so this is a good chance to add support for them.

alex-l added a comment.EditedJun 12 2019, 8:57 AM

Maybe this is just a perception from the point of view of the icons. When looking at the two images, I don't see a perceptible change with the titlebar height, but I notice it with the icons. If the icons were consistently the same size and the titlebar a different height, would that be good?

Title bar is 4px narrower, maybe title height and icons size could be changed without decreasing the clickable area

Edit: here there is a mockup, the title bar height is the same, the icons are smaller and the clickable area is bigger and change background color when hovering. It feels better to me:

Edit: here there is a mockup, the title bar height is the same, the icons are smaller and the clickable are is bigger and change background color when hovering. It feels better to me:

I like that. Having the clickable area extend to the end of the frame like on Windows is better from a usability standpoint because you don't have to aim so precisely. Especially if your window is maximized you can just jam your mouse in the corner and click to close.

That's not bad!

BTW the actual hitbox is already a larger area for the close button when the window is maximized or tiled. I agree that it would be nice for the hitbox to be that large for all buttons all the time, and for the visuals to match the actual hitbox size.

@alex-l would yo mind filing a bug report or a child phab task to track that?

mglb added a comment.Jun 12 2019, 2:47 PM

Edit: here there is a mockup, the title bar height is the same, the icons are smaller and the clickable area is bigger and change background color when hovering. It feels better to me:

The button active area already extend to the corner when window is maximized, so this makes sense. I even thought it works like that in normal window already heh.

However, what are the chances for misclick when resizing a window in the corner? Wouldn't be a problem?

In T10201#188279, @mglb wrote:

Edit: here there is a mockup, the title bar height is the same, the icons are smaller and the clickable area is bigger and change background color when hovering. It feels better to me:

The button active area already extend to the corner when window is maximized, so this makes sense. I even thought it works like that in normal window already heh.

However, what are the chances for misclick when resizing a window in the corner? Wouldn't be a problem?

The resize area is outside the window area, so I don't think it's a problem.

@ngraham I opened this, I hope everything is OK: https://phabricator.kde.org/T11082

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.
For narrow windows:

  • it would stay a hamburger button,
  • or the menubar is cut off somewhere with a drop down button.

The text in the menubar could be placed a bit downwards, to indicate that it belongs to the application, not the window system.

Of course, this does not work for browsers which have no menubar by default.

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.
For narrow windows:

  • it would stay a hamburger button,
  • or the menubar is cut off somewhere with a drop down button.

    The text in the menubar could be placed a bit downwards, to indicate that it belongs to the application, not the window system.

    Of course, this does not work for browsers which have no menubar by default.

If you mean something like this it's a nice idea for me (WARNING: mockup made in 5 min):

Yes, mostly.

You have the menubar labels vertically centered, I would have them moved a little downwards.

And problem: Your menubar is at another position than the menubar hamburger button in the narrow window. I wouldn’t align title and menubar in the same direction, that makes them harder to distinguish.

Maybe it’s better to move the menubar to the left, where it is in most applications. The window title would be aligned right. Would that be ok? (I’m used to right aligned window titles, it felt somehow “fresh breeze” the first time...)

ndavis added a comment.EditedJun 12 2019, 9:05 PM

@davidhurka Here's my go at making something like what you described:

M151 : Dynamic Locally Integrated Menu

This mockup is using settings that I personally use such as Breeze Dark the titlebar button configuration and the left aligned window title, but those are not actually part of my idea. It was just easier to use my own setting in the mockup than to switch to a different user with default settings.

That looks perfect to me.

And keeping the hamburger button visible this way is also good. It probably teaches users where to look for the menubar when the window is too narrow.

Another option would be displaying a label "Menu" instead of the hamburger menu when the window is narrow and File Edit View... labels when there is enough space and dragging area

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.Tue, Nov 12, 4:43 PM
mglb added a comment.Tue, Nov 12, 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.Tue, Nov 12, 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.Tue, Nov 12, 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.EditedTue, Nov 12, 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.Sat, Nov 16, 8:45 PM

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

ndavis added a comment.EditedSat, Nov 16, 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.Mon, Dec 2, 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.Mon, Dec 2, 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.EditedMon, Dec 2, 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.