Bug 433307 - Have the same corner radius for all 4 window corners
Summary: Have the same corner radius for all 4 window corners
Status: CONFIRMED
Alias: None
Product: kwin
Classification: Plasma
Component: decorations (other bugs)
Version First Reported In: unspecified
Platform: unspecified All
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-20 09:12 UTC by Dimitris Giannos
Modified: 2025-04-09 17:26 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Window corners when snapped to screen corners/edge (35.91 KB, text/plain)
2021-02-23 10:32 UTC, Dimitris Giannos
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitris Giannos 2021-02-20 09:12:51 UTC
Just a suggestion. I see that, in breeze, the top 2 edges of the windows have bigger curve than the bottom 2 edges. Is it possible that the bottom 2 edges have the same curve as the one of the other 2? Or, in general, all four share the same curve?
Comment 1 Nate Graham 2021-02-22 21:57:49 UTC
Yes it's possible. There are various methods:

1. Turn on Breeze theme Window borders. You can do this yourself right now. Downside: the window KWin-drawn borders generally look ugly for 3rd-party apps and modern KDE apps.

2. Change all apps to round the bottom corners themselves. Downside: needs to be implemented for every app/toolkit, which means that it will take forever, be inconsistent, and never get applied to 3rd-party apps.

3. Have KWin automatically round the bottom corners of all free-floating SSD-using apps. Downside: by clipping away some window content, there is the remote possibility of removing important app-drawn content that lives in those corners.

There is a lot of user and VDG demand for this, and most VDG members favor option 3, but some KWin developers are hesitant for various reasons. If it ever gets done, it would probably be implemented as a KWin effect that can be disabled for the rare cases where it causes problems, or for people who philosophically disagree with the idea of the window manager clipping any app content.
Comment 2 Lucas 2021-02-23 03:30:23 UTC
(In reply to Nate Graham from comment #1)

> Downside: by clipping away some window content, there is the
> remote possibility of removing important app-drawn content that lives in
> those corners.

I would say this is close to non-existent in the case of the default 3px radius. That's more or less 4 affected pixels per corner, smaller that than a period char ".". I have yet to see an application put anything important this small in the very corner.

In any case, a blacklist option could be added to the effect.
Comment 3 Nate Graham 2021-02-23 04:48:05 UTC
When it comes to option 3, there appear to be two types of opinions on the matter:

"I am very uncomfortable with this idea for philosophical reasons, and will try very hard to think up implausible use cases that will break with it"

"I can't think of any actual real-world use cases that matter which harmed by this idea, and will minimize any that are presented"

:)

We did some brainstorming in the VDG today and managed to come up with precisely one use case where it would actually be a functionality or usability regression (not just being ugly): a drawing or painting app where the canvas extends all the way to the bottom edge of the window with no sidebars on either side, such that the bottom left and bottom right corners of the window can be painted on. If KWin removes a few pixels from these corners, those areas would become unpaintable when the window is free-floating and has no scrollbars. This is admittedly a fairly remote scenario, but it's possible and not acceptable.

Of course if this effect is implemented as a KWin effect, it can be disabled. And we would also not clip corners for tiles, maximized or full screen windows. But you would have to know about those things, and it would still be broken for free-floating windows. And an app blacklist is not generally the kind of engineering solution favored by KDE devs. We don't break apps, ask users to find the breakage, and then selectively turn off our breakage. That's neither realistic or kind.

---

Regardless, there is an option 4 that I forgot: add subtle lines to the edged of windows with feathered ends. This creates a fairly convincing illusion of rounded corners without actually rounding them or clipping any app content! Downsides include a low upper bound to the effective corner radius that it's possible to achieve, and also some people might not like an additional contrast line drawn around the edges of windows. There is an open MR with this: https://invent.kde.org/plasma/breeze/-/merge_requests/67
Comment 4 Dimitris Giannos 2021-02-23 06:55:37 UTC
 Then, how about no curvy edges and just angles? Although I think this will lool, perhaps, too strange for Plasma. I don't know.
Comment 5 Dimitris Giannos 2021-02-23 10:32:11 UTC
Created attachment 136078 [details]
Window corners when snapped to screen corners/edge

 Could also add a new feature (not sure how had to implement:
 In the image you can see that, even though the windows have been snapped both to screen corners and the 2 windows' top corners together, the corners remain curvy. How about when a windows is brought to, for example. be snapped to the bottom right corner of the screen then the same window corner (top right) be "squared" (with angle, no curve)? And similar case when 2 windows snap together and in the same time snapped to a screen's edge, just like in the image perhaps?
Comment 6 Nate Graham 2021-02-23 15:35:53 UTC
Yes, when a window is tiled, maximized, or full screen, we would not round the corners. In fact we already do this for the top corners. So we would continue to do that for the rounded bottom corners too.