Window borders
Closed, ResolvedPublic

Description

By default, KWin draws a thin border around all windows (this is user-controllable in System SettingsApplication StyleWindow DecorationsBorder Size).

The border's color is the window background color from the theme, and there is no line separating it from the rest of the window content.

This border causes some aesthetic issues. In particular, when a window has content right up against its own natural edge that is very different in color from the border that KWin draws, the result is somewhat awkward:

In other cases, when the color discrepancy is small, the result is less noticeable but nonetheless causes perceived visual glitches: lines don't touch the edge of the window, toolbars and lists abruptly end, background colors change with no visual separation between them, etc:

In other cases, the additional KWin-drawn border causes a "double border" effect where elements are twice as far away from the window's edge than they should be:

The problem here is that today's software--including all non-KDE software--is increasingly written with the expectation that their content is able to touch the window's edges, and our default border setting interferes with that and causes visual issues. It also limits our own design flexibility by making it difficult to design according to Breeze's own minimalistic style. An example is how System Settings' sidebar tries to be Breezey and minimalistic by using only a single-pixel line to separate itself from the content area, but because of the border, the line doesn't extend all the way to the bottom of the screen, and the list background color differs from the border color:

Thoughts on how we resolve this?

There are a very large number of changes, so older changes are hidden. Show Older Changes
alex-l removed a subscriber: alex-l.Jun 2 2018, 2:14 PM

Thanks for coming back, Hugo!

There are two primary arguments:

  • Many apps (Kirigami, 3rd-party) look ugly with borders.
  • The borders hinder KDE's ability to design our own apps to have content areas which touch the window edge, which has a very nice clean modern look that we want to move towards, and that IMHO is actually a fulfillment of Breeze's minimalistic design vision.

On the subject of 3rd-party apps, I think it does us no favors to ignore about them. It hurts our platform as a whole when Firefox, LibreOffice, GIMP, Blender, Inkscape, VLC, Telegram, and other flagship non-KDE Linux apps don't look right because of constraints or design decisions we've made in KDE-land. We of course have no control over the layout of the widgets in the windows, but we do have a measure of control over their visual styling, and total control over the window decorations. It's not about them breaking our design decisions but rather the opposite: since they've all been developed around the expectation of not having a visible window border (because no other desktop platform has window borders like we do), we break them when we add one.

We aren't the only show in town, and IMHO our users deserve for non-KDE apps to look nice too when they chose our platform.

Thanks for coming back, Hugo!

There are two primary arguments:

  • Many apps (Kirigami, 3rd-party) look ugly with borders.
  • The borders hinder KDE's ability to design our own apps to have content areas which touch the window edge, which has a very nice clean modern look that we want to move towards, and that IMHO is actually a fulfillment of Breeze's minimalistic design vision.

Disregarding the discussion on third party apps.
The fact that kirigami apps look ugly with borders is a problem. It is not fixed by making the default "no borders".
As long as we (kde) offer the option of having non zero borders (disregarding the default) then our own apps *must* look good with these options enabled. period.
We cannot say we offer an option, but if you turn it on, then all our apps will look ugly.
Îf I as a user see that there is this option available, turn it on, and then see that all application becomes broken (or ugly, quoting your own words), I get a pretty bad impression on the software I am using.
So either we fix the app, or we remove the option (non-zero border) entirely.
In either case, changing the default value has nothing to do with this.
It is just hiding a problem under the carpet.

On the subject of 3rd-party apps, I think it does us no favors to ignore about them. It hurts our platform as a whole when Firefox, LibreOffice, GIMP, Blender, Inkscape, VLC, Telegram, and other flagship non-KDE Linux apps don't look right because of constraints or design decisions we've made in KDE-land. We of course have no control over the layout of the widgets in the windows, but we do have a measure of control over their visual styling, and total control over the window decorations. It's not about them breaking our design decisions but rather the opposite: since they've all been developed around the expectation of not having a visible window border (because no other desktop platform has window borders like we do), we break them when we add one.

On this second argument, I don't buy it sorry.
Many apps these days are developed in the logic of being run fullscreen. Not running them fullscreen, it is us that break them. Does that mean that we should start all our apps fullscreen by default ?

davidedmundson added a comment.EditedJun 2 2018, 8:24 PM

I think that's remediable.

The current palette of the side border matches matches the background colour of some widget apps to visually not have a border. It makes an optimisic assumption about the contents of the app which is getting less and less true. We get something that sort of looks like the client has half a border in some places and not others. This makes the client look broken - our "bug".

IMHO not a problem on default openbox, because the border colour is so distinct that it looks like an border.

If we did have no border as default, we wouldn't need to be trying to do a fake no-border by making colours match as default. If it was dark grey and a user enabled the borders I don't think it'd be ugly.

The fact that kirigami apps look ugly with borders is a problem. It is not fixed by making the default "no borders".
As long as we (kde) offer the option of having non zero borders (disregarding the default) then our own apps *must* look good with these options enabled. period.
We cannot say we offer an option, but if you turn it on, then all our apps will look ugly.

There's no accounting for taste, but...

Some of the color schemes in the color KCM make apps look hideous. We let people use 24pt Comic Sans as their system font if they want. We ship, by default, the incredibly ugly Plastik and "MS Windows 9x" window decoration and widget styles.

I could go on, but I think you get the point. :) We already have a thousand options where, "if you turn it on, then all our apps will look ugly". We're not GNOME; if you want to make your system look ugly, you can.

Again, it's not just about ugliness. It's about the inability to design our own apps--Kirigami and QWidgets apps alike--to have content areas that touch the window edges. I'll concede that the ability to crank up the borders to huge size so that you can have a bigger drag-resize target is an accessibility feature, which is why I don't propose to remove the borders entirely (but note that going from "Normal" to "None" doesn't change their size at all, it only affects the appearance). We accept minor visual regressions in the name of accessibility; check out the High Contrast color scheme. IMHO it seems sane to say, "by default, our apps will be beautiful, but if you want or need enormous click targets for window resizing, then no problem, you can turn on these gigantic borders."

On this second argument, I don't buy it sorry.
Many apps these days are developed in the logic of being run fullscreen. Not running them fullscreen, it is us that break them. Does that mean that we should start all our apps fullscreen by default ?

C'mon Hugo, I don't think you believe this. You're trying to extend my argument to its logical conclusion to make it look silly, but it doesn't work because your premise is wrong: desktop apps are generally NOT designed to be run full-screen all the time. Now, some have a full screen MODE, and in that mode, yes, we still have a responsibility to not make them look ugly, if at all possible (though in full screen mode, the presentation really is mostly up to them, not us).

We have a responsibility not to make 3rd-party apps look ugly as much as we can. It's about the attractiveness of the platform as a whole.

The fact that kirigami apps look ugly with borders is a problem. It is not fixed by making the default "no borders".
As long as we (kde) offer the option of having non zero borders (disregarding the default) then our own apps *must* look good with these options enabled. period.
We cannot say we offer an option, but if you turn it on, then all our apps will look ugly.

There's no accounting for taste, but...

Some of the color schemes in the color KCM make apps look hideous. We let people use 24pt Comic Sans as their system font if they want. We ship, by default, the incredibly ugly Plastik and "MS Windows 9x" window decoration and widget styles.

I could go on, but I think you get the point. :) We already have a thousand options where, "if you turn it on, then all our apps will look ugly". We're not GNOME; if you want to make your system look ugly, you can.

This is a very reductive way (if not insulting) of describing kde's configurability. Please avoid such rhetorical shortcuts, if you don't want to throw people away from the discussion.

Again, it's not just about ugliness.

you are the one using "ugly" over and over as an argument for making people accept this change.

It's about the inability to design our own apps--Kirigami and QWidgets apps alike--to have content areas that touch the window edges. I'll concede that the ability to crank up the borders to huge size so that you can have a bigger drag-resize target is an accessibility feature, which is why I don't propose to remove the borders entirely

Making the desing of the apps so that it fits both using borders and no-borders is a constrains that the design should satisfy. Not the other way around. This is "constrained" design. You are reverting the argument. If you want to remove the constrain, so be it, but that is not changing the defaults.

(but note that going from "Normal" to "None" doesn't change their size at all, it only affects the appearance).

I don't understand that. Normal is non zero pixels allocated to borders, none is zero pixels. How is this not changing their size ?

We accept minor visual regressions in the name of accessibility; check out the High Contrast color scheme. IMHO it seems sane to say, "by default, our apps will be beautiful, but if you want or need enormous click targets for window resizing, then no problem, you can turn on these gigantic borders."

On this second argument, I don't buy it sorry.
Many apps these days are developed in the logic of being run fullscreen. Not running them fullscreen, it is us that break them. Does that mean that we should start all our apps fullscreen by default ?

C'mon Hugo, I don't think you believe this.

Please.
That again is insulting.
I believe this, and this is why I wrote it.
In fact, I believe that people designing their apps to have no window borders expects them either to be used as full screen, or to be resized by some area which is outside the window. This second expectation is a broken one (see the case for tiled windows). That's why I mentioned the first.

You're trying to extend my argument to its logical conclusion to make it look silly, but it doesn't work because your premise is wrong: desktop apps are generally NOT designed to be run full-screen all the time.

See above.

Now, some have a full screen MODE, and in that mode, yes, we still have a responsibility to not make them look ugly, if at all possible (though in full screen mode, the presentation really is mostly up to them, not us).

We have a responsibility not to make 3rd-party apps look ugly as much as we can. It's about the attractiveness of the platform as a whole.

ngraham added a comment.EditedJun 3 2018, 2:12 AM

The drag resize area for "No Borders" is identical to the drag resize area for "Normal" borders. It becomes bigger if you make the borders larger, but it doesn't get any smaller. This is why I keep saying that there is no functional change from moving from "Normal" to "No Borders". It is a purely visual change.

Do you have a proposal for resolving the issues brought up in the original post, Hugo? If so, I'll be glad to entertain it.

hpereiradacosta added a comment.EditedJun 3 2018, 8:16 AM

The drag resize area for "No Borders" is identical to the drag resize area for "Normal" borders. It becomes bigger if you make the borders larger, but it doesn't get any smaller. This is why I keep saying that there is no functional change from moving from "Normal" to "No Borders". It is a purely visual change.

Fair enough. But the one for "no border" is outside of the window.

Do you have a proposal for resolving the issues brought up in the original post, Hugo? If so, I'll be glad to entertain it.

1/ fix kirigami apps so that they can accomodate having a window border.
That would be my preference although it does not work for third party apps. In fact, I would have expected that kirigami apps were designed from the beginning with the idea in mind that windows can have borders, since kde offers the possibility to have borders around windows. In the same way that they were designed so that they can accommodate multiple color palettes and not just the default, since kde offers the possibility to change color palettes, multiple icon themes, etc. When designing something (anything) for KDE and within KDE, IMHO you have to consider all the options and combinations of options that we offer to the users up-front, and not only an arbitrarily limited set of them.

2/ change how decoration border are rendered so that they appear more like window borders and not as a possibly imperfect extension of the window, to make kirigami apps look better with them.

3/ devise a way so that applications can tell the window manager (or the decoration) that they want no border, disregarding the user's default choice. (along the line of CSD but maybe less drastic).

None of these have anything to do with changing the default, which again, does not fix the original issue, just hides it.

I would veto anything with solution #1.

Kirigami looks fine with a actual border.

Breeze is using a hack to make it look like there is no visual border even when one is set. This behaviour relies on a false assumption. That is a bug, pure and simple.

Any app specific change is working round a bug instead of addressing the root problem.

hpereiradacosta added a comment.EditedJun 3 2018, 9:52 AM

I would veto anything with solution #1.

No objection.

Kirigami looks fine with a actual border.

Glad to hear that. (I don't recall having read that once in this long thread so far).

Breeze is using a hack to make it look like there is no visual border even when one is set. This behaviour relies on a false assumption. That is a bug, pure and simple.
Any app specific change is working round a bug instead of addressing the root problem.

No objection either.
I am not convinced about this being a bug, but agree that addressing this is a valid way to fix the issues mentioned at the top of the post.
Inputs from the VDG are welcome.

If this is only a matter of window border color, this requires both some change in breeze palette but also some minor change in the code, to use the proper color role.

If we want something more elaborate, then again: open for suggestions, mockups etc. I volunteer to review patches and/or participate to the coding.

hein added a comment.Jun 3 2018, 4:03 PM

David's argument a few comments up is convincing to me personally.

David makes a great point that the "border" actually isn't a border at all in most QWidgets-based apps since it's designed to blend in in with what's expected to be the window background color. It seems instead to be a vehicle for rounding the corners and providing a drag area for window resizing (though at some point, the drag area was made semi-independent of the actual border for small-to-normal sizes).

@anemeth offered an interesting idea in https://phabricator.kde.org/T8707#142103. While I'm not sure that's the visual look we're going for, I think it does suggest that when the border actually is serving as a visual border, more contrast rather than less would make it look better (though perhaps not as much as in Alex's mockups). I bet the current border would look better in Kirigami and 3rd party apps if it had a 1px dark gray line separating it from the window content. Warning: very very crude mockup incoming:

I think I'd still like "No Borders" by default, but I would strongly support an effort to make the border prettier when it's actually being a border in Kirigami and 3rd-party apps.

anemeth added a comment.EditedJun 3 2018, 7:02 PM

@ngraham it looks weird at the top where the titlebar and the sideborder contact
How about a nice gradient between them?


(This would be just a breeze specific change)

I'll have to defer to the more artistically-gifted members of VDG than myself on that. :)

abetts added a comment.Jun 3 2018, 7:43 PM

@ngraham it looks weird at the top where the titlebar and the sideborder contact
How about a nice gradient between them?


(This would be just a breeze specific change)

Looks-wise, this "could" be an enclosed box inside the window. I have seen this particularly from web apps adapted to the desktop. Could there be the same amount of margin/border space that is at the bottom/sides at the top as well?

mart added subscribers: alex-l, mart.Jun 4 2018, 8:56 AM
In T8707#143269, @zzag wrote:

+1 for no-side borders by default. Also, titlebar and bottom border can have custom colors using KWin rules (for example if a distro ships Telegram it can ship in the same package a KWin rule to match colors), so consistency is not a issue there. The real issue is that apps draw widget near the side borders, so we just need to disable them by default. I use this settings since KDE4 and I have no issues with it.

That's okay only for windows with white background. For example,

here's Google Chrome in Incognito mode. At least for me, that's really awkward.

Is there a method to have the bottom border copy the color of the UI?

yes, we have a protocol for that. I don't know if our browser extension thing can make use of it, may be difficult as the browser isde is just javascript

mart added a comment.Jun 4 2018, 9:02 AM

I've got a few confusions from this thread.

*IF* windows borders are an accessibility thing, then it doesn't meet requirements to have any solution where applications can turn them off at will.
It's solvable with some sort of config option which sets the border to size to be a preference or an override, but then you get into overly complex code and complex UI and I don't think it's solving anything.

For accessibility, what we really need i think is a single switch to turn everything more accessible, i think ideally a look and feel theme, which changes in one go the color scheme to high contrast, bigger fonts, and probably yeah, setting big window borders all around as well.

mart added a comment.Jun 4 2018, 9:43 AM

We are not going to clip anything away from the windows. Sorry, but we cannot do that. It's in IMHO absolutely evil to clip away window content. If you want round borders follow the approach I outlined.

it's really eveil as it can break random applications, yes...
but what about there is a protocol that first asks to the window if it's ok to round, and does it only if the app answers yes?

mart added a comment.Jun 4 2018, 9:52 AM

I would veto anything with solution #1.

Kirigami looks fine with a actual border.

Breeze is using a hack to make it look like there is no visual border even when one is set. This behaviour relies on a false assumption. That is a bug, pure and simple.

Any app specific change is working round a bug instead of addressing the root problem.

so another question here is: is possible to make breeze still looking nicehaving a border which is an actual border? (like, the titlebar color all aound, like most decorations used to do)
it would still look somewhat ugly, but if still having the option for borders is clearly an accessibility option, it would make it way more accessible for sure, as the border would get actually visible and not pretend there is no border even when there is as is doing now

romangg added a comment.EditedJun 4 2018, 9:57 AM
In T8707#146055, @mart wrote:

We are not going to clip anything away from the windows. Sorry, but we cannot do that. It's in IMHO absolutely evil to clip away window content. If you want round borders follow the approach I outlined.

it's really eveil as it can break random applications, yes...
but what about there is a protocol that first asks to the window if it's ok to round, and does it only if the app answers yes?

This is the third option from above (only that not the compositor, but the client does it):

Clients only paint an alpha to their surface bottom corners, but not any additional shadows and top bar, which are still provided as SSD. This is some kind of bastard between CSD and SSD and an API to communicate this to the client would be very specific about alpha rounded corners. Basically this is Martin's solution b) whereas he wants to reuse the shadow protocol for that.

I'm not sure if the shadow protocol is suitable for that. Maybe another option is a semi-generic protocol for minimal, selective CSD like this: Compositor sends information on which corners / sides of its surface the client should alter, and what it should do (alpha, color gradient, possibly more).

So for our Breeze case the compositor would send some event like: alphaGradient(bottomLeft | bottomRight, radius)

mart added a comment.EditedJun 4 2018, 10:00 AM
In T8707#146056, @mart wrote:

so another question here is: is possible to make breeze still looking nicehaving a border which is an actual border? (like, the titlebar color all aound, like most decorations used to do)
it would still look somewhat ugly, but if still having the option for borders is clearly an accessibility option, it would make it way more accessible for sure, as the border would get actually visible and not pretend there is no border even when there is as is doing now

something along the lines:


which looks older, but more accessible and couldn't ever be the default

I don't know if our browser extension thing can make use of it,

Unfortunately not, there's no way to get the native window from the extension API. Even if we could do a hack (that was what that annoying flashing new tab was for, btw) on X, we're certainly doomed on Wayland without the browser's support.

In T8707#146062, @mart wrote:
In T8707#146056, @mart wrote:

so another question here is: is possible to make breeze still looking nicehaving a border which is an actual border? (like, the titlebar color all aound, like most decorations used to do)
it would still look somewhat ugly, but if still having the option for borders is clearly an accessibility option, it would make it way more accessible for sure, as the border would get actually visible and not pretend there is no border even when there is as is doing now

something along the lines:


which looks older, but more accessible and couldn't ever be the default

Yes, @anemeth brought up this option at the very beginning of the thread. I agree that its very dated, heavyweight appearance means that it couldn't ever be the default. I think it's possible to find a visual compromise though, which I tried to do here: T8707#146004

(That said I still think no visible borders by default is the look we want)

mart added a comment.EditedJun 4 2018, 1:10 PM

Yes, @anemeth brought up this option at the very beginning of the thread. I agree that its very dated, heavyweight appearance means that it couldn't ever be the default. I think it's possible to find a visual compromise though, which I tried to do here: T8707#146004

(That said I still think no visible borders by default is the look we want)

yeah, that would be fine as well.
how would it look on non focused windows?

emateli added a subscriber: emateli.Jun 4 2018, 1:30 PM

I just want to chime in with a little observation (sorry if this had been addressed before, the thread is huge).

Note in the current screenshots:

Note with the border drawn with the same color as the title bar:

If you pay attention, in the current one it looks as if the title bar decoration stops 1-2 pixels before the end of the frame, whereas it does not look that way in the second screenshot. This visual "bug" is also not present when the title bar is a light color. This currently happens regardless of border settings.

Also FWIW, + 1 on the border color matching title bar color rather than the background.

I'm really sorry for how this discussion turned out, everyone.

I'd like to propose a do-over for this discussion, and this time I promise to involve all stakeholders, listen honestly, and not pre-suppose a particular solution. How does that sound?

abetts added a comment.Jun 4 2018, 8:59 PM

I'm really sorry for how this discussion turned out, everyone.

I'd like to propose a do-over for this discussion, and this time I promise to involve all stakeholders, listen honestly, and not pre-suppose a particular solution. How does that sound?

Let's do that. From this discussion, at least, we know more about the technical difficulties about implementing. Maybe we can work around that. I am all for coming up with a community solution on this.

hein added a comment.EditedJun 4 2018, 9:21 PM

Let's approach it from a visual point of view, perhaps.

Let's consider a window sans any decorations, i.e. the client area rectangle. Our system provides clients with a system color palette. The system color palette contains a window background color. The expected default case is that the client area rectangle is solid-filled with the window background color, or something visually close to this (Oxygen used a gradient fill).

Now, window decorations. The system palette also contains a color for window title bars. Typically, this would be a color that contrasts from the window background color. Decorations now broadly-speaking have two choices when it comes to putting a border around the client rectangle on all sides: They can have this corder visually extend the client rectangle by filling the border with the window background color, or they can make the border have contrast to the client area by using the title bar color.

Breeze colors borders using the window background color. Plastik uses the title bar color.

Classic widget-based apps for the most part - though not fully - work OK with both. What constitutes "working" vs. "not working"? It's mostly about the window bg color borders case and whether the edges of the client area content have widgets along them that are designed to exist in a sea of window background color or not. For example, take a standard list view with a standard rectangular frame: It's designed to embed into a fill of window bg, so a border color that extends this sea is OK. What doesn't work, on the other hand, is edge-aligned widgets that expect the edge to terminate in a contrast color, i.e. either no border or a contrasting border. An example of this in classic widget apps is putting QTabBar in "document mode", which hides the tab widget frame and makes the tab bar baseline run the width of the widget and terminate by cut-off. This has always looked visually very awkward with both the Breeze and the Oxygen decos, so this is not a new problem.

Now we have to contend with a growing variety of applications that do whole lot of things like QTabBar does in document mode. They eschew frames, and they will run hard-contrasting horizontal and vertical lines right up to the edges of the client area, expecting it to terminate in contrast. These applications include our own Kirigami apps, but also many third-party apps shown earlier in the ticket.

Where is this design trend coming from? Mobile. On mobile, there are no window borders: There's only the screen edge, which provides hard contrast, and it's OK to run things up to the screen edge. As a result, there's now an entire zoo of new common widgets (such as drawers, etc.) and visual conventions that are designed around this assumption.

I think this design trend isn't going to go away. In particular, I don't think we want to redesign Kirigami's widgets to work any differently. I don't see the gain, and at this point I think it'd ill-serve users who have built up new familiarity and skills using this UI generation.

This means we have two options: We can either do away with window background-colored borders (arguably this was always a misuse of the system color palette) and go with no borders, or we can make the borders a contrasting color.

I get the feeling most of us don't want a contrasting color border, or we wouldn't have switched from Plastik to Oxygen and then Breeze. This hasn't been our preference for a long time now.

So, what option if not "No borders" is there really? "Then Kirigami should just be fixed" as has been voiced a few times is short of supplying any ideas on what that fix would look like while retaining what Kirigami does, and it'd still not be comprehensive ("third-party apps don't matter" isn't a very practical stance, especially if they just follow the same motivations we do, so it's hard to fault them really).

Then there's the whole IMHO only tangentially related (it's a wholly seperate design question!) question of whether windows should have rounded corners at the bottom or not. Personally, I don't find these important. With my engineering hat on, meanwhile, I don't find them feasible: Masking the client area is IMHO not acceptable, which means they could only be done by using CSDs with participation of the clients. We don't want CSDs for various usability/accessibility/technology reasons, and that we could get all clients to use them consistently is a pipe dream, considering the slow, hard-fought process of getting even "assume SSDs" standardized so far.

abetts added a comment.Jun 4 2018, 9:25 PM
In T8707#146163, @hein wrote:

Let's approach it from a visual point of view, perhaps.

Let's consider a window sans any decorations, i.e. the client area rectangle. Our system provides clients with a system color palette. The system color palette contains a window background color. The expected default case is that the client area rectangle is solid-filled with the window background color, or something visually close to this (Oxygen used a gradient fill).

Now, window decorations. The system palette also contains a color for window title bars. Typically, this would be a color that contrasts from the window background color. Decorations now broadly-speaking have two choices when it comes to putting a border around the client rectangle on all sides: They can have this corder visually extend the client rectangle by filling the border with the window background color, or they can make the border have contrast to the client area by using the title bar color.

Breeze colors borders using the window background color. Plastik uses the title bar color.

Classic widget-based apps for the most part - though not fully - work OK with both. What constitutes "working" vs. "not working"? It's mostly about the window bg color borders case and whether the edges of the client area content have widgets along them that are designed to exist in a sea of window background color or not. For example, take a standard list view with a standard rectangular frame: It's designed to embed into a fill of window bg, so a border color that extends this sea is OK. What doesn't work, on the other hand, is edge-aligned widgets that expect the edge to terminate in a contrast color, i.e. either no border or a contrasting border. An example of this in classic widget apps is putting QTabBar in "document mode", which hides the tab widget frame and makes the tab bar baseline run the width of the widget and terminate by cut-off. This has always looked visually very awkward with both the Breeze and the Oxygen decos, so this is not a new problem.

Now we have to contend with a growing variety of applications that do whole lot of things like QTabBar does in document mode. They eschew frames, and they will run hard-contrasting horizontal and vertical lines right up to the edges of the client area, expecting it to terminate in contrast. These applications include our own Kirigami apps, but also many third-party apps shown earlier in the ticket.

Where is this design trend coming from? Mobile. On mobile, there are no window borders: There's only the screen edge, which provides hard contrast, and it's OK to run things up to the screen edge. As a result, there's now an entire zoo of new common widgets (such as drawers, etc.) and visual conventions that are designed around this assumption.

I think this design trend isn't going to go away. In particular, I don't think we want to redesign Kirigami's widgets to work any differently. I don't see the gain, and at this point I think it'd ill-serve users who have built up new familiarity and skills using this UI generation.

This means we have two options: We can either do away with window background-colored borders (arguably this was always a misuse of the system color palette) and go with no borders, or we can make the borders a contrasting color.

I get the feeling most of us don't want a contrasting color border, or we wouldn't have switched from Plastik to Oxygen and then Breeze. This hasn't been our preference for a long time now.

So, what option if not "No borders" is there really?

Then there's the whole IMHO only tangentially related (it's a wholly seperate design question!) question of whether windows should have rounded corners at the bottom or not. Personally, I don't find these important. With my engineering hat on, meanwhile, I don't find them feasible: Masking the client area is IMHO not acceptable, which means they could only be done by using CSDs with participation of the clients. We don't want CSDs for various usability/accessibility/technology reasons, and that we could get all clients to use them consistently is a pipe dream, considering the slow, hard-fought process of getting even "assume SSDs" standardized so far.

What would be the effects of these proposals on current windows? Examples? Screenshots?

hein added a comment.Jun 4 2018, 9:31 PM

Sorry, I don't have time to take screenshots currently. The proposals in the text can be mimicked with seperate settings also mentioned there. I'll not summarize them here again because I don't think it helps if no one actually reads the full big picture :).

abetts added a comment.Jun 4 2018, 9:32 PM
In T8707#146165, @hein wrote:

Sorry, I don't have time to take screenshots currently. The proposals in the text can be mimicked with seperate settings also mentioned there. I'll not summarize them here again because I don't think it helps if no one actually reads the full big picture :).

No worries. Thanks for your work.

That's pretty much where I find myself, Eike.

People who have been around for far longer than me can confirm or deny this, but it seems that the border has historically been a tool for rounding the bottom corners and increasing the window edge's drag resize area. I think it's notable that the design does not seem to have involved a desire for visible borders like older versions of Windows and macOS had--or else the chosen border color wouldn't have been the theme's window background color. Most of our QWidgets-based apps render a window background color that matches the border color on all three sides, so they don't have a visible border. But from the start, several of our apps didn't conform: Konsole, Okular, Gwenview, and DragonPlayer, for example. They have always displayed a visible border around 1-3 of their window edges because of their developers' design preferences for content areas that can touch the window edge. And as mentioned, the number of apps that don't conform to the original background color and content area expectations is rising all the time--including many of our own. I think Eike is right that this design trend isn't going away.

The resize area issue was rendered moot for smaller-than-normal border sizes at some point in the past with a clever change that allowed windows with "No Borders" to keep the extended resize areas of a window with "Normal" borders. We may be able to come up with a similarly elegant way to handle the (important) case of people who want larger resize areas, and perhaps we can agree to compromise on the desire for rounded bottom corners, since there are technical pitfalls and risks involved in gaining them without a KWin-drawn border.

mart added a comment.Jun 6 2018, 6:30 PM

That's pretty much where I find myself, Eike.

...original background color and content area expectations is rising all the time--including many of our own. I think Eike is right that this design trend isn't going away.

many trends have came and gone, but the one thing that has been rising pretty much since the invention of the gui with no regressions, is the trend to use more and more area for the content and less and less for the chrome, so it's realistic to expect more cases of images, videos, or whatever "multicolored content" to go right at the edges, without a trend inversion possibly ever.
The gray that Breeze puts there, it's just the most typical "chrome color".

The resize area issue was rendered moot for smaller-than-normal border sizes at some point in the past with a clever change that allowed windows with "No Borders" to keep the extended resize areas of a window with "Normal" borders. We may be able to come up with a similarly elegant way to handle the (important) case of people who want larger resize areas, and perhaps

That case is really different, and that's why showing borders should still be available, and they shout really be visible (as opposed than current breeze which tries to be invisible): who is visually and/or motion impaired just want a target that is really big and really visible, with zero consideration whatsoever about it looking "pretty" or "dated". So that's why while the default should be without borders, they should still be there as an option, and they should be ugly

We are not going to clip anything away from the windows. Sorry, but we cannot do that. It's in IMHO absolutely evil to clip away window content.

Why is clipping anything away from the window so bad? Breeze already has the "Add handle to resize windows with no border" option which draws on top of the windows. If it ok to draw on top of corners then it should also be ok to crop away from corners, no?

I'm asking because I know that cropping is exactly how OS X achieves its very beautiful combination of no borders and windows that are rounded at both the top and the bottom. There are several benefits to doing the rounding server side: 1/ The window manager can ensure that the rounding is consistent across all applications. 2/ The user can easily change the rounding across all applications. 3/ The window manager can with a very simple implementation ensure that the rounding and the shadows match.

So, there are many practical benefits for cropping (and it works great for OS X). Are there any practical reasons for not doing it?

mart added a comment.Jun 13 2018, 4:16 PM

So, there are many practical benefits for cropping (and it works great for OS X). Are there any practical reasons for not doing it?

I guess if there ever was some tiny interactive control at the corner of the window, tough seems quite an edge case

If anyone interested there is a KWin effect that rounds the corners of windows.
Here is my fork of it with a few tweaks: https://github.com/alex47/KDE-Rounded-Corners

Before:

After:

I'd keep the same amount of rounding as we currently have, but having all four corners rounded with no border in general looks fantastic to me.

Discover also integrates nicely

Does your effect keep the corners square when the window is tiled or maximized?

Does your effect keep the corners square when the window is tiled or maximized?

Square corners when maximized, rounded when tiled

That would represent a visual change and possibly a functional regression, as right now tiled windows also get square corners. This allows the top-right pixel on the screen to activate the close button for a window that's tiled to the right side or top-right corner. That still needs to work.

Can the effect be tweaked to do squared tiling?

The resize area issue was rendered moot for smaller-than-normal border sizes at some point in the past with a clever change that allowed windows with "No Borders" to keep the extended resize areas of a window with "Normal" borders.

I'm not a designer, so whatever you guys cook up is fine with me. But it would be nice if this hidden resize value was a setting somewhere, especially if there is a push to remove borders. I've actually set mine to Very Large, since I run 2x scaling on HiDPI, and want to use my finger on my touchscreen to resize a window sometimes. And even then it's a bit too thin, I must have fat fingers. ;) I'd rather not see the borders and just have a hidden resize area though, if that were possible.

Thinking forward, it would be appreciated that whatever design is chosen, keeps touch-input in-mind. Even though Kirigami is designed to make convergent apps pleasant, many devices now-even my last two smartphones-support picture-in-picture apps, and the resizing of them. It would be nice to keep/improve on that functionality in Plasma for phones/tablets into the future.

That is really awesome @anemeth. I've just compiled it with great results.

I tried increasing the radious of the rounding by changing the value in the code here. It works fine but it then becomes apparent that the rounding isn't perfect. It still looks great when the corners are over a dark area but when over a light area the rounding looks off. It's like the opacity isn't completely right. It is actually also visible in the screenshot you posted. If you look closely (or zoom in) on the lower right corner on the window with Konqi you can see that a few pixels are "off".

Anyway, despite the above, I think the effect looks really great. I know it's subjective, but I think equal rounding on all corners increases consistency.

I'm not a designer, so whatever you guys cook up is fine with me. But it would be nice if this hidden resize value was a setting somewhere, especially if there is a push to remove borders.

Yes, I think it's absolutely certain that rounding all corners would be optional, in the same way that it is optional to draw a little black triangle on top of the content in the bottom-right corner of the window.

I think the point @mart made was that the borders, when visible, should be visible. They shouldn't try to cleverly fade into the window background like they do right now, because it doesn't really work, not even with many of our own apps. And it impairs the accessibility and touch use cases by still not clearly showing you where the drag area is. If a big fatty border looked like a big fatty border, there would be no issue there.


We had a number of in-person discussions at Akademy about going with No Borders by default and my recollection was that all were generally in favor of the concept, but there were a few remaining technical sticking points that folks wanted resolved. One that I can recall was the case of two windows butted up against one another: with No Borders, it takes two clicks to resize the lower window by the shared edge: one click to raise it, and then a second click to resize the shared edge.

If I recall, @romangg or @apol @mart came up with some clever idea to handle this use case. Do any of you guys remember who it was and what the ideas was?

No, I don't remember. But I don't think it's really a problem. I have used no window borders setting now for several months and never felt annoyed with the resize area over other windows.

What @acrouthamel said is a problem though. I also have problems finding the right touch point when trying to resize windows without borders. With borders it's probably still not really nice, but better.

Making the resize area configurable in size is not a way I want to go. This is not something to customize, but should work right out of the box with all methods of input. I propose to start from a blank slate when thinking about how resizing windows with touch could be done nicely with and without borders.

I can confirm that it's still no fun even with borders. :( No Borders isn't much of a regression there because of how awkward it is with the current default settings. I agree that the whole concept needs a re-think for the touch use case.

Do we have a path forward for this?

It still looks great when the corners are over a dark area but when over a light area the rounding looks off. It's like the opacity isn't completely right. It is actually also visible in the screenshot you posted. If you look closely (or zoom in) on the lower right corner on the window with Konqi you can see that a few pixels are "off"

You mean this right?

That outer gray border is part of the Breeze shadow. Solving THIS will be a challenge.

You mean this right?

I think the vertical and horizontal gray lines look great. Less so the diagonal ones that make up the corner.

I think the vertical and horizontal gray lines look great. Less so the diagonal ones that make up the corner.

Yes, I meant the contrats outline in the corner specifically.

abetts moved this task from Backlog/Planned to Work in Progress on the VDG board.Sep 30 2018, 4:58 AM
zzag added a comment.Oct 1 2018, 3:58 PM

Is it really "WIP"?

In T8707#162233, @zzag wrote:

Is it really "WIP"?

Well there are patches:

All we need to do is more forward with them.

Roman's point about the too-small invisible drag-resize region is well-taken, and we might want to consider increasing its size. I dug through KWin's code yesterday but couldn't find where that's set though.

zzag added a comment.EditedOct 1 2018, 4:11 PM

Roman's point about the too-small invisible drag-resize region is well-taken, and we might want to consider increasing its size. I dug through KWin's code yesterday but couldn't find where that's set though.

IIRC, the decoration plugin sets that (by calling setResiezOnlyBorders).

I created a task for brainstorming a distinct window touch resize interaction pattern: T9780

In T8707#162236, @zzag wrote:

Roman's point about the too-small invisible drag-resize region is well-taken, and we might want to consider increasing its size. I dug through KWin's code yesterday but couldn't find where that's set though.

IIRC, the decoration plugin sets that (by calling setResizeOnlyBorders).

Ah no wonder, it was in Breeze and I was looking in KWin! Thanks @zzag.

I am surprised to see how much (almost all) of the discussion here goes around personal opinions and no effort or intention is seen in bringing in objective facts, research papers, articles, examples, trends etc. I found it irresponsible to decide upon a product used by millions of people this way.

@harogaston would you like to add anything to the record?

@ngraham I could. I went scouting for examples of "the competition" trying to go borderless. Results vary, in form and execution. Some have rounder bottom corners and some don't, some have an outline and others have not. I went through the list of top window managers (taken from https://www.slant.co/topics/390/~best-window-managers-for-linux and https://wiki.archlinux.org/index.php/Window_manager) to find examples of borderless themes. Unsurprisingly I left out tiling window managers.

Awesome:


Emerald:


Fluxbox:



Gala:


Jwm:


Metacity:



Muffin:




Mutter:

Openbox:

Xfwm:





Misc Linux WM:




Windows:



MacOs:



Full disclosure I might have gotten some of the images wrong, I only used Google, sorry about that.
That been said, and regarding a point made by @graesslin about accessibility, I really don't see how changing the default hinders accessibility in any way. As long as you provide options for people with those special needs, that should be left in hands of distribution managers to include in theirs install processs option to enable accessibility feature. What I mean is that it is one thing to support and BE an accessible platform and a different thing is "let's make all most accessible options the default ones". It is easy to see that the two most widely used OS have almost borderless windows and that does not make them any less accessible, and I asume they have special configuration for those scenarios as well.

The compendium of WMs I just did more or less objectively share a common aesthetic, which is not random, and the images where also not randomly picked (although sort of). I think that arguably they represent many common features seen in (pos)modern consumer oriented desktops.

  • Sorry about my English, it is not my mother tongue.
Luwx added a subscriber: Luwx.Oct 3 2018, 2:18 AM

^
Although most of these desktops are customized, one common thing is that all of them has either no border or a 1 pixel border.

With this, I think that breeze deco could really use a stronger outline around the window, specially for dark themes, as the shadow on dark backgrounds is not that noticeable.

Default breeze:

Stronger outline:

With a bright color scheme:

abetts added a comment.Oct 3 2018, 3:43 AM
In T8707#162405, @Luwx wrote:

^
Although most of these desktops are customized, one common thing is that all of them has either no border or a 1 pixel border.

With this, I think that breeze deco could really use a stronger outline around the window, specially for dark themes, as the shadow on dark backgrounds is not that noticeable.

Default breeze:

Stronger outline:

With a bright color scheme:

I am pretty torn about this. I honestly don't see the beauty of having a stronger border. I think we could use a border that is visible but not necessarily a strong border. Even in some examples earlier, there were plenty of dark themes where you couldn't see the border, but that didn't make them any less effective in conveying that you indeed have a border. I am more for subtle, visible, but not an in-your-face approach. It will distract people to the frame and not the window content IMHO. If there are ways to tweak the borders when using dark themes, that would be great too.

Thanks for all the pictures, @harogaston. I believe they demonstrate what has been brought up: that everyone is moving towards reducing the window chrome as much as possible and getting rid of explicit borders. Those that still have borders make them visible and contrasting. We appear to be unique in having multi-pixel window borders that try to pretend they're not actually there by having as little contrast as possible. I will once again agree with @mart: by default, Breeze should have no borders, but if you opt to add them, they should be visible, not camouflaged.

I find myself agreeing with @Luwx that a stronger "contrast pixel" might be desirable around the window edges. Nowhere near as strong as depicted in the screenshots though; something nice and subtle, not attention-getting. That's sort of a nice-to-have though.

If the default is that there are no borders (not even a technically-there-but-invisible-border) then, when users turn on borders, it makes sense that there should be a clearly visible border since the user explicitly asked for it.

Clearly visible borders that change color based on whether or not the window is active has a usability effect in that they make the currently active window easier to identify. I think that should be taken into consideration as well.

emateli removed a subscriber: emateli.Oct 23 2018, 5:59 PM
filipf added a subscriber: filipf.EditedOct 23 2018, 7:04 PM

I would strongly lobby against a single pixel border. I believe it adds nothing and yet it's an annoyance from a design point of view. It's pretty clear where the window ends with out them; the shadows are enough when there isn't much contrast. I know that the Breeze HiG is already in favor of 1px strokes as well, but I just don't see any top notch design and designers using it (so obviously) and personally as someone who's pretty passionate about design I generally find single pixel strokes ugly. They may be good for specific uses (e.g. as separators), but shouldn't be a key design element. Yes, Windows does it, however those guys are really not the champions of design and from what I've read they will at least make it so that the it's not painted with an accent color, but with a subtler grey. We don't want our design to look like Windows or xfwm4, however, we want something better and should look up to the more established names when it comes to design.

That being said, I think having no borders is a perfectly fine solution, but maybe the hit area for resizing could be increased a bit. Although Linux shouldn't be about the developer culture, I'd add one more argument and that's that if I'm a developer who cares a great deal about the visual aspect of my program, I would be annoyed if my vision is being overridden and if something likes this happens:

rooty added a subscriber: rooty.EditedOct 23 2018, 7:14 PM

Thanks for all the pictures, @harogaston. I believe they demonstrate what has been brought up: that everyone is moving towards reducing the window chrome as much as possible and getting rid of explicit borders. Those that still have borders make them visible and contrasting. We appear to be unique in having multi-pixel window borders that try to pretend they're not actually there by having as little contrast as possible. I will once again agree with @mart: by default, Breeze should have no borders, but if you opt to add them, they should be visible, not camouflaged.

I find myself agreeing with @Luwx that a stronger "contrast pixel" might be desirable around the window edges. Nowhere near as strong as depicted in the screenshots though; something nice and subtle, not attention-getting. That's sort of a nice-to-have though.

i also agree there's no need for thick borders by default

rooty added a comment.Oct 23 2018, 7:19 PM
In T8707#162405, @Luwx wrote:

^
Although most of these desktops are customized, one common thing is that all of them has either no border or a 1 pixel border.

With this, I think that breeze deco could really use a stronger outline around the window, specially for dark themes, as the shadow on dark backgrounds is not that noticeable.

Default breeze:

Stronger outline:

With a bright color scheme:

but why? it interrupts the continuity of the theme and disrupts the relationship between the edge/side of a window and the shadow it casts - there's really no need for any kind of outline here, the edge of the window is the outline

if you think about it, it's the same argument used for keeping the really thick borders in place too, if we're to impose a 1 px outline on every window, it's not much different from leaving the thick default border we've got right now

Codezela removed a subscriber: Codezela.Oct 24 2018, 9:02 AM
Codezela added a subscriber: Codezela.

This is moving forward, so for comparison's sake, here's how the major closed-source OSs handle window resizing in various cases:

macOS

  • There is no concept of maximized windows; instead there are full screen windows which cannot be resized at all.
  • IIRC a non-full-screen window cannot be resized from a window edge that is touching a screen edge or the Dock (but don't quote me on that since I may be misremembering, and I don't have any Macs handy to verify with)

Windows

  • A maximized window cannot be resized at all, just like macOS full screen windows.
  • A non-maximized or tiled window can be resized from any edge, including the edge shared with the Taskbar.
    • For an edge shared with a taskbar, the resize area overlaps the taskbar by a few pixels, and for these pixels, the taskbar cannot be interacted with.
    • For a window edge shared with the screen edge, the resize area is one pixel thick and overlaps the window content, meaning the window cannot be interacted with on those pixels. This is actually really annoying in the case of a scrollbars on the right and the window's close button, since they cannot be dragged/clicked from those key pixels while the window is tiles to the right
    • When two windows are tiled side-by-side, they share an edge and resizing that edge resizes both windows, which is a feature KWin does not currently have

Compared to KWin, when borders are turned off:

  • A maximized window cannot be resized at all: same thing. Probably fine
  • For a window edge shared with a panel, the window cannot be resized from that edge. This is something that Windows can do.
  • For a window that's tiled or non-maximized but adjacent to a screen edge, you cannot resize the window from that edge. I think this is fine since the alternative is to interfere with the window's own content and prevent using the all-important line of pixels next to the screen edge to interact with scrollbars or the close button (Fitts' Law)

Right now KWin has IMO a better behavior than MS Windows does because a tiled or screen-edge-touching window's own content is never obscured to draw internal resize areas. The only area we might want to look into is allowing a window edge touching a panel to be resizable by drawing the resize area over a few pixels of the panel. However when the window is tiled, currently none of the other edges would be resizable, so that might be weird. If we do this, I would recommend only doing it for the somewhat niche case of a non-tiled window that nonetheless shares an edge with a panel.

ngraham closed this task as Resolved.Jun 6 2019, 8:54 PM
ngraham moved this task from Work in Progress to Done on the VDG board.