Summary: | Have the same corner radius for all 4 window corners | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Dimitris Giannos <aclassifiedmail> |
Component: | decorations | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | CONFIRMED --- | ||
Severity: | wishlist | CC: | aoeui, kwin-bugs-null, luwx, nate |
Priority: | NOR | ||
Version First Reported In: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | All | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | Window corners when snapped to screen corners/edge |
Description
Dimitris Giannos
2021-02-20 09:12:51 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. (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. 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 Then, how about no curvy edges and just angles? Although I think this will lool, perhaps, too strange for Plasma. I don't know. 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?
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. |