To test this for example with Breeze you need to recompile Breeze with the following change:

diff --git a/kdecoration/breeze.json b/kdecoration/breeze.json
index ca4a4e3..bb94302 100644
--- a/kdecoration/breeze.json
+++ b/kdecoration/breeze.json
@@ -64,6 +64,7 @@
     },
     "org.kde.kdecoration2": {
         "blur": false,
+        "borderSizeRecommended": "None",
         "kcmodule": true
     }
 }

EDIT: property name changed with revision 3 to recommendedBorderSize

FWIW, on first glance, I don't have any objections to this. I'll offer more comments later!

I like this approach. What I had as idea was to make border size a property of DecoratedClient and introduce a window specific rule. I haven't followed up on it as the vdg did not show any interest in me improving the code side of things.

Hi Roman, Martin
First, I think the approach is sound (and moves the discussion about default window borders from kwin to breeze ;))
Only (minor) drawback that I can see is that users now have two actions to change the window border size instead of one: uncheck the use recommanded size, then select in the combobox. No big deal.

To Martin, on the window rule: I know this is not the right place to discuss it, but still:
It would be really nice to have ! Right now both oxygen and breeze decorations implement "exceptions" which are essentially a crippled version of window rules. Moving the window border size out of this crippled version to the upstream and more feature complete version provided by window rules would be quite awesome.

In D13284#272895, @hpereiradacosta wrote:

> To Martin, on the window rule: I know this is not the right place to discuss it, but still:

It would be really nice to have ! Right now both oxygen and breeze decorations implement "exceptions" which are essentially a crippled version of window rules. Moving the window border size out of this crippled version to the upstream and more feature complete version provided by window rules would be quite awesome.

yep, that's where I got the idea from and is also part of the thinking of how can we improve KWin and at the same time improve on the area vdg wants to see improved.

BTW, just to clear the air a bit, the reason why we didn't like the previous technical proposal made in T8707 was not because of its technical nature, but rather because it didn't actually solve the original problems and seemed to introduce the risk of visual regressions. If this alternative technical proposal doesn't have those issues, then I think we're all for it! Not being a technical expert on the KWin side, I'm not going to stand in the way of whatever you guys come up with as long as it meets the design goals without introducing visual regressions. I also rather like the fact that the borders become theme-specific, because then we can say that Breeze doesn't want borders, but Oxygen, which is fine with them, doesn't have to follow suit. Seems like it gives theme makers more flexibility.

I'm glad this is something that it seems we can all converge on, and I'll be happy to abandon my earlier patches if we move forward with this! I'm sorry that the discussion in T8707 got so heated, and it'll be nice if we can have everyone walk away satisfied in the end. :)

Here's a UI idea: Instead of "Auto border size", how about inverting the logic and combining the checkbox and the combobox's label, like this:

[x] Override theme's default border size in favor of: [ Normal Borders ⮟ ]"

In D13284#273208, @ngraham wrote:

Here's a UI idea: Instead of "Auto border size", how about inverting the logic and combining the checkbox and the combobox's label, like this:

[x] Override theme's default border size in favor of: [ Normal Borders ⮟ ]"

I like it. I also thought of radio buttons:

Border size:
(o) Automatic
( ) Manual: [ Normal Borders ⮟ ]

But to be honest I left it like it is, because I don't want to put too much effort into this old QWidget based KCM (which is rarely opened). When we rewrite it with Kirigami Form layouts we can improve upon the current solution. The theme selection view is QML already.

I had thought about radio buttons too, but that would require an extra vertical line, which is maybe okay? I'm okay with leaving off the major UI improvements for the Kirigami front-end rewrite. I imagine this would mostly use a gridlayout instead of a formlayout though, right?

Explaining why I prefer this approach over changing the default in KWin. It mostly comes from a rule for code changes: "it works together with all existing features" (see https://community.kde.org/KWin/Mission_Statement ). KWin ships one window decoration (Plastik as a QML Aurorae theme). As explained Aurorae does not support no (side) border as that doesn't match what Aurorae was designed for and is not possible to add without breaking the existing themes. Thus the change of the default conflicts with an existing feature in KWin and is thus not possible from the rules KWin has.

The approach here moves the change to no side border to breeze, thus does not conflict KWin's rules. It also follows ideas from the KDecoration design process to give lots of power to the decoration.

Nevertheless I want to add that I still think that switching to no border is IMHO the wrong solution to the problem the VDG wants to address. No border won't help for Kirigami apps running outside of Plasma and won't help with a change of the decoration. In addition I see an accessibility issue. With no side borders it's difficult to recognize which window will be resized for adjacent windows.

Nevertheless I want to add that I still think that switching to no border is IMHO the wrong solution to the problem the VDG wants to address. No border won't help for Kirigami apps running outside of Plasma and won't help with a change of the decoration. In addition I see an accessibility issue. With no side borders it's difficult to recognize which window will be resized for adjacent windows.

This may not be entirely true if the window selected keeps a shadow underneath. The selected window will overshadow the window adjacent to it. Therefore, you will see that one is selected and which one is not. The one that is selected will get the focus, so will the ability to use the border handles to resize. If you want to resize the other window, in this example, you click on it to give it focus and the borders activate for the user to resize.

In D13284#274448, @abetts wrote:

Nevertheless I want to add that I still think that switching to no border is IMHO the wrong solution to the problem the VDG wants to address. No border won't help for Kirigami apps running outside of Plasma and won't help with a change of the decoration. In addition I see an accessibility issue. With no side borders it's difficult to recognize which window will be resized for adjacent windows.

This may not be entirely true if the window selected keeps a shadow underneath. The selected window will overshadow the window adjacent to it. Therefore, you will see that one is selected and which one is not. The one that is selected will get the focus, so will the ability to use the border handles to resize. If you want to resize the other window, in this example, you click on it to give it focus and the borders activate for the user to resize.

yes. So something you could do in one click, you now do in two clicks, and by targetting a region which is outside the window you want to resize. In my humble oppinion, this is not "simple by default".

In D13284#274456, @hpereiradacosta wrote:

In D13284#274448, @abetts wrote:

Nevertheless I want to add that I still think that switching to no border is IMHO the wrong solution to the problem the VDG wants to address. No border won't help for Kirigami apps running outside of Plasma and won't help with a change of the decoration. In addition I see an accessibility issue. With no side borders it's difficult to recognize which window will be resized for adjacent windows.

This may not be entirely true if the window selected keeps a shadow underneath. The selected window will overshadow the window adjacent to it. Therefore, you will see that one is selected and which one is not. The one that is selected will get the focus, so will the ability to use the border handles to resize. If you want to resize the other window, in this example, you click on it to give it focus and the borders activate for the user to resize.

yes. So something you could do in one click, you now do in two clicks, and by targetting a region which is outside the window you want to resize. In my humble oppinion, this is not "simple by default".

That's fair to say. I feel it is still very doable. It doesn't seem complex for me. It is what MacOS does, for example.

No border won't help for Kirigami apps running outside of Plasma and won't help with a change of the decoration.

It will.

That thread is an absolute mess, but underneath it's a really simple problem that's been very poorly explained and evidently poorly understood.

• Kirigami looks fine with a border. It is not broken outside of the Breeze decoration on Plasma.

• Breeze is using a clever hack to make it look like there is no visual border even when one is set. This behaviour relies on a false assumption and therefore results in things looking broken.

That is the part we need to finish so it's done properly. I'm fully on board with this patch that does it on a per theme basis.

something something Accessibilty

Breeze currently has no visual borders.

If you set breeze style to no size borders and you add to breeze

BreezeStyle::polish() { if (widget->isWindow() { widget->setContentMargins(2,0,2,0);}

QWidget apps will look pixel for pixel identical.

In D13284#274466, @davidedmundson wrote:

No border won't help for Kirigami apps running outside of Plasma and won't help with a change of the decoration.

It will.

That thread is an absolute mess, but underneath it's a really simple problem that's been very poorly explained and evidently poorly understood.

• Kirigami looks fine with a border. It is not broken outside of the Breeze decoration on Plasma.
• Breeze is using a clever hack to make it look like there is no visual border even when one is set. This behaviour relies on a false assumption and therefore results in things looking broken.
  
  That is the part we need to finish so it's done properly. I'm fully on board with this patch that does it on a per theme basis.

something something Accessibilty

Breeze currently has no visual borders.

If you set breeze style to no size borders and you add to breeze

BreezeStyle::polish() { if (widget->isWindow() { widget->setContentMargins(2,0,2,0);}

QWidget apps will look pixel for pixel identical.

Is this already implemented in the patch? Are we just debating the merits of looks at this point? Is the patch going to move forward?

If you set breeze style to no size borders and you add to breeze

BreezeStyle::polish() { if (widget->isWindow() { widget->setContentMargins(2,0,2,0);}

QWidget apps will look pixel for pixel identical.

I don't understand that. You still can not resize from these extra two pixels. Can you ?

In D13284#274466, @davidedmundson wrote:

No border won't help for Kirigami apps running outside of Plasma and won't help with a change of the decoration.

It will.

That thread is an absolute mess, but underneath it's a really simple problem that's been very poorly explained and evidently poorly understood.

• Kirigami looks fine with a border. It is not broken outside of the Breeze decoration on Plasma.
• Breeze is using a clever hack to make it look like there is no visual border even when one is set. This behaviour relies on a false assumption and therefore results in things looking broken.
  
  That is the part we need to finish so it's done properly. I'm fully on board with this patch that does it on a per theme basis.

That breeze (and oxygen) might need "proper" border is indeed a discussion worth having (and which is taking place elsewhere). It is completely orthogonal with the discussion on setting the default to no-border (and in fact, adding "proper" borders to breeze might go in the direction of _not_ setting the default to no-border, if I understand the reasoning well)

It is also quite interesting in a platonian way because this discussion is what led (some ten years ago) to the fork between oxygen and ozone, and ultimately to me starting to work with kde. Time keeps repeating itself.

QWidget apps will look pixel for pixel identical.

I don't understand that. You still can not resize from these extra two pixels. Can you ?

I meant they'd visually be the same

As for resize handles, that's a valid question.

With the current code as-is:

• Hit area would be actually bigger!
• They would be shifted to not include kwin's current non-visual border

What I'm concerned about is accessibility. Accessibility in the case of users who learned that they need to hover over the border of a window. In case of an adjacent window they get the resize handle of the window, but it resizes the other window. This is totally unexpected and I wouldn't know how to explain this to my mother.

Even worse is the situation of two inactive windows not bordering but shadows overlapping. There is then no visual hint at all which window is going to be resizes.

In D13284#274570, @graesslin wrote:

What I'm concerned about is accessibility. Accessibility in the case of users who learned that they need to hover over the border of a window. In case of an adjacent window they get the resize handle of the window, but it resizes the other window. This is totally unexpected and I wouldn't know how to explain this to my mother.

Even worse is the situation of two inactive windows not bordering but shadows overlapping. There is then no visual hint at all which window is going to be resizes.

One solution that I proposed early in the VDG channel discussion was to have a border that was 1 PX. It looks like an outline, it preserves a visible border as well. Would this be feasible?

In D13284#274486, @davidedmundson wrote:

QWidget apps will look pixel for pixel identical.

I don't understand that. You still can not resize from these extra two pixels. Can you ?

I meant they'd visually be the same

As for resize handles, that's a valid question.

With the current code as-is:

• Hit area would be actually bigger!
• They would be shifted to not include kwin's current non-visual border

ok so the answer is no you cannot resize from these two pixels

In D13284#274572, @abetts wrote:

In D13284#274570, @graesslin wrote:

What I'm concerned about is accessibility. Accessibility in the case of users who learned that they need to hover over the border of a window. In case of an adjacent window they get the resize handle of the window, but it resizes the other window. This is totally unexpected and I wouldn't know how to explain this to my mother.

Even worse is the situation of two inactive windows not bordering but shadows overlapping. There is then no visual hint at all which window is going to be resizes.

One solution that I proposed early in the VDG channel discussion was to have a border that was 1 PX. It looks like an outline, it preserves a visible border as well. Would this be feasible?

Doable yes
Now, with this solution, if you keep the resize from outside the window feature, it does not solve any of the issues pointed by Martin (in fact it makes them worse in some cases, for instance when the shadow of one window is above the outline of the other ) while if you don't, then there is only one pixel available for resizing.

There's one more case where the no-border resize is problematic: when compositing is disabled. Then we don't have shadows so the resize handles would really indicate it's the other window.

That's a non-standard definition of the word accessibility.

For impaired users it is an improvement as we have a larger default hit area for the window we are more likely to be changing, the active one.
I would be happy to agree it's behavioural regression for those with fine sniper like precision.

Even worse is the situation of two inactive windows not bordering but shadows overlapping.

In theory yes. In practice window snapping defaults are larger than the default resizeOnlyBorder hints, so it's a very difficult occurence to be in.

But moving in terms of brainstorming things that would improve everything generally, we could replace replace using this arrow <--> with the icon that looks like |<- or ->| as appropriate. It doesn't change which object is changing, but would resolve any potential confusion. (GTK apps do this)

It's orthogonal to this patch, so unless there are immediate objections, I shall make a patch for that.

In D13284#274781, @davidedmundson wrote:

That's a non-standard definition of the word accessibility.

I consider support for elderly people also accessibility. And that's the group of people I mostly have in mind here. As said: I cannot imagine how I could explain that to my mother who learned that windows resize on the border.

For impaired users it is an improvement as we have a larger default hit area for the window we are more likely to be changing, the active one.
I would be happy to agree it's behavioural regression for those with fine sniper like precision.

Even worse is the situation of two inactive windows not bordering but shadows overlapping.

In theory yes. In practice window snapping defaults are larger than the default resizeOnlyBorder hints, so it's a very difficult occurence to be in.

For breeze: yes, for Oxygen: no.

---

But moving in terms of brainstorming things that would improve everything generally, we could replace replace using this arrow <--> with the icon that looks like |<- or ->| as appropriate. It doesn't change which object is changing, but would resolve any potential confusion. (GTK apps do this)

It's orthogonal to this patch, so unless there are immediate objections, I shall make a patch for that.

small problem: our code uses Qt::CursorShape but Qt doesn't have those in the enum. I think that's the main reason why it doesn't exist.

In D13284#274794, @graesslin wrote:

For breeze: yes, for Oxygen: no.

erm sorry, I wrote bullshit.

In D13284#274794, @graesslin wrote:

I consider support for elderly people also accessibility. And that's the group of people I mostly have in mind here. As said: I cannot imagine how I could explain that to my mother who learned that windows resize on the border.

Unless your mother uses Plastik or another window decoration theme with an always-visible border, you didn't actually teach her to resize windows on the border, because most KDE apps don't have a visible border with the Breeze or Oxygen window decoration themes. Instead you must have told her to resize on the window edge, in which case nothing changes from her perspective.

If anything, the real accessibility issue here is the fact that the border is visibly distinct in some apps but not others. I find myself agreeing with Marco in T8707#146401 that resolving this inconsistency should involve making the border into an actual always-visible border. There are various design proposals for that in there.

in which case nothing changes

No.

Let me try translating from KWin->VDG now.

• Currently we don't have any extended border allowing you to resize from outside the window.
• With this change we activate that (and have to)
• This means the target window being resized is partly based on whether it's active (z-depth) than the exact x/y position.

I don't think it's remotely a problem that it changes. IMHO it's now a lot easier to know which is being resized in the side-by-side scenario, defaulting to the one you probably actually want without requiring the needle-eye mouse precission typically only held by heavy duty PC gamers, heart surgeons and Martin's mother.

But nonetheless it is a behavioural change.

Thanks David. I must be getting confused by the fact that right now, if a user switches to No Borders, there is indeed an extended resize area outside of the window's bounds (at least for me; do you not see this?). If this patch preserves it, than that's good.

In D13284#275069, @ngraham wrote:

Thanks David. I must be getting confused by the fact that right now, if a user switches to No Borders, there is indeed an extended resize area outside of the window's bounds (at least for me; do you not see this?). If this patch preserves it, than that's good.

This patch does nothing. It just moves the behavior change from KWin to breeze.

I'd like to re-visit this because it makes a lot of sense: Some window decoration themes (like Plastik) are designed to have a visible border that stands out from the content, while others (like Breeze) are not. So Because themes have different needs and design goals regarding whether or not to show a border, it makes sense to allow themes to make their preferences clear.

Breeze's border tries its best to disappear as though it were borderless (but fails with many windows), so it appears that the only reason why Breeze even has a border at all is to work around the lack of this feature, and to provide rounded bottom corners without clipping window content.

The former issue is solved by this patch, and the latter issue can be solved with an optional KWin effect like @anemeth's https://github.com/alex47/KDE-Rounded-Corners, or just accepted as the price to pay for having no borders. Either way, I would like to move forward with this. @romangg, any chance you'd like to rebase the patch on current master and proceed with review?

BTW the KCM itself is now done in QML so UI changes are fun and easy. :)

In D13284#430583, @ngraham wrote:

@romangg, any chance you'd like to rebase the patch on current master and proceed with review?

In general yes. But in regards to no-borders I found one usability issue after using it now for several months: a window can't be resized by starting a drag from the screen edge if the window is adjacent to a screen edge. There should be maybe a one pixel line to drag the window from in this case. Same holds for a window adjacent to a panel.

Since the use case of this patch here is primarily enabling no borders per default in Breeze, we should first find a solution for that usability issue. Is one pixel line a solution?

If the line is invisible, sure. I don't think we want to draw a visible line for that.

In D13284#430594, @ngraham wrote:

If the line is invisible, sure. I don't think we want to draw a visible line for that.

I wholehartedly agree.

@romangg are you planning to submit a patch for that? It would be nice to get this unblocked :)

(This comment is somewhat offtopic from this exact patch, but I can't find the relevant thread)

In order to facilitate one of the (legitimate) concerns with this patch I added support for kwin to support 9 different resize cursors.
i.e <-- or --> instead of <-->

This way if you have two windows close to each other you know what you're resizing.

I asked for the relevant icons in breeze to complete that feature and resolve the concern nearly a year ago, https://bugs.kde.org/show_bug.cgi?id=395247 they still haven't landed !

In D13284#459599, @ngraham wrote:

@romangg is going to submit another patch to work on the niggling issue with being able to resize an un-maximized/tiled window that's touching a panel edge.

I've inspected this issue some more. I believe a solution would be to copy the outmost client pixels to a narrow artificial border whenever no border is shown. But we need to decide on some special cases (maximized windows resizable?) and maybe this needs a change in KDecoration lib as well. I'm not sure it's really worth it. I think we should wait for feedback if people miss this feature or how is it solved in other desktops? The overall logic in regards to window borders adjacent to special objects feels somewhat inconsistent to me in KWin. Are there some common rules to it?

In D13284#460836, @davidedmundson wrote:

(This comment is somewhat offtopic from this exact patch, but I can't find the relevant thread)

In order to facilitate one of the (legitimate) concerns with this patch I added support for kwin to support 9 different resize cursors.
i.e <-- or --> instead of <-->

This way if you have two windows close to each other you know what you're resizing.

I asked for the relevant icons in breeze to complete that feature and resolve the concern nearly a year ago, https://bugs.kde.org/show_bug.cgi?id=395247 they still haven't landed !

I'll see if I can rouse VDG to get us some appropriate icons. However I don't think this is a blocker because the rule is pretty simple: for a shared /nearby edge, the window on top is the one that gets resized. This is visually hinted by the fact that the upper window shadows the lower one. It's also the behavior seen on macOS, Windows, and GNOME, so people are pretty accustomed to it and it doesn't seem to be a usability issue. We can do better of course, but I think it's not a blocker.

In D13284#461278, @romangg wrote:

In D13284#459599, @ngraham wrote:

@romangg is going to submit another patch to work on the niggling issue with being able to resize an un-maximized/tiled window that's touching a panel edge.

I've inspected this issue some more. I believe a solution would be to copy the outmost client pixels to a narrow artificial border whenever no border is shown. But we need to decide on some special cases (maximized windows resizable?) and maybe this needs a change in KDecoration lib as well. I'm not sure it's really worth it. I think we should wait for feedback if people miss this feature or how is it solved in other desktops? The overall logic in regards to window borders adjacent to special objects feels somewhat inconsistent to me in KWin. Are there some common rules to it?

I've added that information to https://phabricator.kde.org/T8707#184088

So, how does that work when user select a specific size, and then change decoration ? Is his choice erased by the default of the new decoration ? Or is his choice maintained (in which case he never gets a chance to actually see the "preferred" width of the new decoration ? And then, if erased by the new default, does that mean that if I switch from decoration A (with custom setting) to decoration B, and then back to A, my custom setting is lost ?

Best,

Hugo

In D13284#464878, @hpereiradacosta wrote:

So, how does that work when user select a specific size, and then change decoration ? Is his choice erased by the default of the new decoration ? Or is his choice maintained (in which case he never gets a chance to actually see the "preferred" width of the new decoration ? And then, if erased by the new default, does that mean that if I switch from decoration A (with custom setting) to decoration B, and then back to A, my custom setting is lost ?

Best,

Hugo

Default is to use the recommended sizes of decorations (falls back to Normal if decoration does not recommend one). User might opt in to specifiy a border size manually instead. This choice is being remembered even if he changes to another decoration. But in this configuration screen he can also opt out to automatic border size again.

In D13284#464924, @romangg wrote:

In D13284#464878, @hpereiradacosta wrote:

So, how does that work when user select a specific size, and then change decoration ? Is his choice erased by the default of the new decoration ? Or is his choice maintained (in which case he never gets a chance to actually see the "preferred" width of the new decoration ? And then, if erased by the new default, does that mean that if I switch from decoration A (with custom setting) to decoration B, and then back to A, my custom setting is lost ?

Best,

Hugo

Default is to use the recommended sizes of decorations (falls back to Normal if decoration does not recommend one). User might opt in to specifiy a border size manually instead. This choice is being remembered even if he changes to another decoration. But in this configuration screen he can also opt out to automatic border size again.

I see. Thanks for the explanation. Sorry for the noise.

Plasma 5.16 has now branched, so if this is land-able, we could do it now/soon and have lots of testing time before 5.17.