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

I don't know if its possible in GTK but we could tint inactive windows as a way of making them lighter.


This has some bugs that would need to be fixed first.

That's more or less what I was thinking of. We can't unconditionally tint or de-saturate the entire window contents like the KWin effect does, since then it would interfere with user content that may be color-sensitive. But I think we can do it for the UI elements that we have control over.

KColorScheme already has infrastructure for tinting inactive windows, some colors already desaturate (most noticeably scroll bars and progress bars) when inactive. There's numerous bugs, especially in QML bits when it comes to this feature. Last time I checked, Kirigami's theme stuff was application global for performance so there's no way for it to change depending on the window's focus state.

Actually, Kirigami.Theme is an attached property these days, so one could probably set the color group to inactive for on a per-window basis

Take a look at these screenshots. Does anything look wrong?



The sidebar content on the left just...ends!

I think for Breeze Light and Breeze dark, we should consider making the titlebar a very slightly different color from the window itself, and/or adding a horizontal line that separates it from the window content. When we don't do that, then any UI elements in the window that butt up against the top margin end up looking really, really weird.

I think for Breeze Light and Breeze dark, we should consider making the titlebar a very slightly different color from the window itself, and/or adding a horizontal line that separates it from the window content. When we don't do that, then any UI elements in the window that butt up against the top margin end up looking really, really weird.

I think just adding a horizontal line would be best, that way all themes benefit from it not just Breeze.

ngraham added a comment.EditedApr 30 2019, 12:19 AM

I think for Breeze Light and Breeze dark, we should consider making the titlebar a very slightly different color from the window itself, and/or adding a horizontal line that separates it from the window content. When we don't do that, then any UI elements in the window that butt up against the top margin end up looking really, really weird.

I think just adding a horizontal line would be best, that way all themes benefit from it not just Breeze.

Agreed. What I've been toying with lately is the idea of adding a horizontal line immediately below the "tools" part of the window, which which consists of the titlebar, menubar, and toolbar.

So for a window with all three, the line would be below the toolbar. For a window with no toolbar but a menubar, it would be below the menubar. For a window with just a toolbar, it would be below the titlebar.

Here's how it would look with Gwenview and the Breeze light color scheme:



And Dolphin:



(Overall the colors themselves may change slightly but hopefully this illustrates the idea of where the line would be and how it would separate the tools from the content).

One more thing to consider: in general it seems more aesthetically pleasing when the titlebar+menubar+toolbar ("tools area") is a little bit darker than the content area. It just somehow seems to anchor the window properly.

I've noticed that GNOME's Adwaita theme used to get a ton of complaints for being ugly, but nobody could really put their finger on why. They recently swapped some colors around so now the titlebar is much darker than the window background and suddenly people love it, and I don't think it's a coincidence.

macOS also uses darker gray titlebars over lighter gray windows and white content areas:


Linux Mint's popular and attractive theme is the same:

So when we move to Breeze Light, I think we should consider slightly darkening the gray background color of the "tools" section of the window, and slightly lightening the gray background of everything beneath it. The tools section doesn't need to be that much darker at all; in fact the gray used in macOS, GNOME, and Linux Mint is probably too dark for us since we need to ensure adequate text and icon contrast due to our use of in-window menubars and borderless/backgroundless toolbar buttons. You can see that the contrast is already a bit low in the Linux Mint screenshot.

Maybe something a bit like this (WARNING: crude mockups incoming)

And then when the window is inactive, its shadow becomes smaller, the tools area lightens:

Now this isn't looking so "light" anymore. Maybe this could be the new Breeze, and Breeze light can be the current version that doesn't paint the tools area with a darker background color.

Kirigami apps with toolbars already do this, in fact:

GB_2 added a comment.Apr 30 2019, 5:59 PM

That would be nice!

Thanks @GB_2! If people like this, implementation-wise here's what I think it would take for us to get this in for Plasma 5.17, in roughly this order (top to bottom):

Can be done at any time because it fixes a pre-existing bug or does not rely on color changes:

  • Change Kirigami and qqc2-desktop-style to add a single-pixel separator line above the page content area and below the titlebar when there's no toolbar
  • Adjust KWin to accept per-window-decoration border sizes - D13284
  • Change Breeze window decoration theme to recommend a border size of "None" - D13284
  • Change Breeze window decoration theme to reduce the shadow size for inactive windows

Must be aligned to Plasma 5.17:

  • Change Breeze and Breeze-GTK widget themes to add a single-pixel separator line below the titlebar, menubar, or toolbar (whichever is the lowest one)
  • Adjust the titlebar background color for the Breeze and Breeze Dark themes to be a little bit darker than the theme's Window Background color (Breeze Light gets no changes)
  • Change Breeze and Breeze-GTK widget themes to use the titlebar color for the toolbars and menubar backgrounds
  • Change Kirigami to use the titlebar color for the toolbars and menubar backgrounds (make sure to only apply this when ≥ Plasma 5.17 since it's a frameworks change, and also don't affect the Material style)

Does this sound sane?

cfeck added a subscriber: cfeck.Apr 30 2019, 6:53 PM

Change Breeze and Breeze-GTK widget themes to add a single-pixel separator line below the titlebar, menubar, or toolbar (whichever is the lowest one)

I tried this with Skulpture in its early days, and had trouble getting it to work. Basically the separator would need to be its own 1 px widget between the central widget and the bars. It might need a Qt patch, or every app changed, or Breeze hacked in an ugly way.

Interesting. I was thinking of having Breeze draw the line itself as the bottom-most pixel of the menubar or toolbar (if present), or the top-most pixel of the view content, but now that I think about it, that could mean obscuring one pixel's worth of content there. Was this the problem you ran into?

cfeck added a comment.Apr 30 2019, 7:38 PM

I think I drew the line as the last pixel of the menu or tool bar, so it didn't cover content. I remember one problem were document windows, which have a framed document area as their central widget. Drawing a separator line clashed with the frame (the frame already acts as a separator). I couldn't find a satisfying logic to deduce if the top bars need to be expanded by a pixel for a separator. It was quite a mess, because the logic both for rendering and sizing was spread around multiple widget types.

Long term, we want to change the visual style (in Breeze at least) so that framed content areas have a more borderless appearance. But yeah, until then I can see that being a bit odd.

Anyway, I appreciate you sharing your wisdom and experience here, and if we decide to move forward with the proposal, it would be great to be able to learn from it.

ngraham renamed this task from Window titlebar colors to Window titlebars.May 6 2019, 4:05 PM
ngraham updated the task description. (Show Details)
ngraham added a comment.EditedJun 1 2019, 9:51 PM

I started looking into using Inactive window effects for this (System SettingsColorsEdit current color schemecheck "Apply effects to inactive windows"go to "Inactive" tab). Overall it works very well and the Contrast: Fade effect is probably what we want. Here's a list of bugs that need fixing before we can do it:

davidhurka added a subscriber: davidhurka.EditedJun 2 2019, 8:54 AM

SierraBreezeEnhanced to the rescue again - what about different window buttons if the window is active or inactive?

Obviously this exact solution would be seen as copying macOS, but maybe just having circles or rings in the active window would help.

I suppose inactive windows could be set to not show the circle around the close button by default, but there should always be visible symbols.

The close button is good to find a window corner, even if the window is mostly hidden by other windows. I think it shouldn’t be circle-less when the window is inactive, that way a visual aid on the window geometry is lost.

Mostly hidden window is easy to locate with the circle arround the close button.

Similar visual guidance was available in Windows XP.

GB_2 added a comment.Jun 2 2019, 9:14 AM

The close button is good to find a window corner, even if the window is mostly hidden by other windows. I think it shouldn’t be circle-less when the window is inactive, that way a visual aid on the window geometry is lost.

Mostly hidden window is easy to locate with the circle arround the close button.

Similar visual guidance was available in Windows XP.

What about turning the filled circle into only a ring/circle outline?

In T10201#186849, @GB_2 wrote:

The close button is good to find a window corner, even if the window is mostly hidden by other windows. I think it shouldn’t be circle-less when the window is inactive, that way a visual aid on the window geometry is lost.

What about turning the filled circle into only a ring/circle outline?

Then, the visual aid is only a bit lost. ;)

Because it would still have a circular edge, the effect for intuitive geometry recognition is probably nearly the same, while the different lightness intuitively tells that the window is inactive.

Titlebar buttons are movable, so it should be configurable which buttons have a circle. Currently, it is just a side effect of the close button being placed in the corner. (Although it’s hard to move the close button, the titlebar control module needs fixing...)

Maybe something a bit like this (WARNING: crude mockups incoming)

And then when the window is inactive, its shadow becomes smaller, the tools area lightens:

Now this isn't looking so "light" anymore. Maybe this could be the new Breeze, and Breeze light can be the current version that doesn't paint the tools area with a darker background color.

+0.9, looks ok to me.

  1. Will the tool area have an own color scheme setting? There will be people who like only the titlebar colored differently.
  2. I don’t like this separator line. Many applications already have a bunch of lines. KDevelop:
  3. Are disabled controls still shown more disabled than others when the window is inactive?
  4. Can you make screenshots of an application like FreeCAD, with its n = n + 1 toolbars?
  5. How will this look with browsers, which have only a tab bar which can follow a color scheme?

Falkon:


Some web browsers put inline controls (the tab bar) between toolbar and titlebar:

I tried to guess a couple of mocks of the style; here's dolphin:

  1. I don’t like this separator line. Many applications already have a bunch of lines. KDevelop:

Like this?

  1. Can you make screenshots of an application like FreeCAD, with its n = n + 1 toolbars?

Oh. I didn't know about it. Wow.

  1. How will this look with browsers, which have only a tab bar which can follow a color scheme? Falkon:

This should be feasible, right?

Some web browsers put inline controls (the tab bar) between toolbar and titlebar:

  1. Can you make screenshots of an application like FreeCAD, with its n = n + 1 toolbars?

Oh. I didn't know about it. Wow.

Don’t like that because it turns a huge area to an area without border. If another window covers the left part, it’s hard to see that this huge area is the tools area of FreeCAD, and not an empty view in the window behind FreeCAD.

But usually, one would arrange the toolbars to use the screen space more efficiently.

Some web browsers put inline controls (the tab bar) between toolbar and titlebar:

This result looks ok. But is there a robust way to tell from the application and to the application that the tab bar is part of the tools area and shall be colored like the titlebar?

Another thought: Context menus.
Clicking on the titlebar opens a KWin(?) menu, and clicking on the toolbar or the tab bar opens a menu with Configure Toolbar or New Tab stuff. Now the separation between these areas is lost.

SierraBreezeEnhanced to the rescue again - what about different window buttons if the window is active or inactive?

Obviously this exact solution would be seen as copying macOS, but maybe just having circles or rings in the active window would help.

I suppose inactive windows could be set to not show the circle around the close button by default, but there should always be visible symbols.

The close button is good to find a window corner, even if the window is mostly hidden by other windows. I think it shouldn’t be circle-less when the window is inactive, that way a visual aid on the window geometry is lost.

Found the option for this: Application Style -> Window Decorations -> Theme -> Breeze -> Configure Breeze -> General -> Draw a circle arround close button.
Could be changed to “Draw a circle arround outermost titlebar button”, assuming that the most interesting button is placed in the corner.

I just want to point out that quite aside from the color of the titlebar and toolbar (which is pretty much the only thing this task is about), the above screenshot depicts a UI catastrophe! It seriously looks like the joke pictures of Internet Explorer or Word that people used to share in the 2000's:

So yes, we should and must consider "Pro" apps, but we cannot fix apps that are already have very problematic user interfaces. I really hope that's not how FreeCad actually looks by default...

ndavis added a comment.Jun 6 2019, 9:35 PM

I really hope that's not how FreeCad actually looks by default...

FreeCAD only has 2 toolbars by default.

I really hope that's not how FreeCad actually looks by default...

FreeCAD only has 2 toolbars by default.

I really hope that's not how FreeCad actually looks by default...

FreeCAD only has 2 toolbars by default.

I did not change anything, that was the default when setting a mode.

So yes, we should and must consider "Pro" apps, but we cannot fix apps that are already have very problematic user interfaces.

(Probably this task shall not be a “fix”, or what will it fix?)
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.

I really hope that's not how FreeCad actually looks by default...

Mostly it is, but FreeCAD is configurable. It is totally possible to use it with only one or two toolbars, then it will probably look like Dolphin.

FreeCAD only has 2 toolbars by default.

I did not change anything, that was the default when setting a mode.

Kind of correct. The toolbars in Freecad usually shove in 2 toolbar rows, with much folding.

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.

alex-l added a subscriber: alex-l.EditedJun 9 2019, 8:20 AM

In my opinion we shouldn't touch Breeze theme for Qt apps or massively redesign KDE apps.
Please consider that KDE apps with Breeze theme could run in a DE without KWin and 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. We should change Breeze theme for window decorations only.

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:

mvourlakos added a comment.EditedJun 9 2019, 3:17 PM

I really like the idea...

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

filipf added a comment.Jun 9 2019, 3:27 PM

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. This has some appeal, although it would unfortunately introduce inconsistency because some apps only have the titlebar (e.g kcms) and it looks clumsy when you spawn the menubar.

@mvourlakos I experimented with this sort of thing before, but there wasn't too much of enthusiasm for it. Personally I also see some drawbacks, but it can look appealing in the right situation (such as the screenshot you just showed!).

ngraham updated the task description. (Show Details)Jun 10 2019, 2:45 PM
ngraham updated the task description. (Show Details)

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.EditedSun, Jul 28, 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.