Rounded window corner support for all non-gtk apps

Desktop
1

Hey there! First, lemme just say that I am new to linux and kind of am unaware of how stuff works under the hood. Few months ago I had posted about a request for rounded corners on non-gtk apps but was told that it was not possible in such a global scale. But then Mac os and windows 11 does that already. But then recently I came accross this mutter-rounded which is a fork of the default mutter compsitor that enables rounded corners for all gtk-3 and non-gtk windows, with some added features. So, Iā€™ve been using that for some time now on fedora 35 on wayland with both intel and nvidia graphics, and with mutter version 41.3-1 and everything seems fine and has no observable hit to the overall performance. Though there has been some bugs with firefox, microsoft edge dev and chrome unstable while running them native on wayland where the bottom corners are buggy and not rendered correctly.

So, is there any plan for the gnome devs to carry this upstream? Because the mutte-rounded implementation seemed quiet solid to me(except for the mentioned issue). Again, as I said, I am relatively new to linux so I might be missing out on some very important details and would love if someone would detail me on some of the important issues with this prospect, but in my opinion, rounded corners for all windows in Gnome should have been done, or atleast discussed of before, given that the gtk4 gnome apps are already heading in that direction.

Thank you for your time!

1 Like
2

Disclaimer: I am not a GNOME dev, and Iā€™m not very knowledgeable in the matter, either, so take everything I say with a grain of salt.

But then Mac os and windows 11 does that already.

I donā€™t think thatā€™s true. macOS and Windows donā€™t clip corners on all windows, either. The corners are rounded using their native toolkits, same as in GNOME if the app uses libadwaita.

The difference is that almost all macOS/Windows apps use the standard, native toolkit at least for the purpose of drawing windows.

On Linux, there is no accepted standard toolkit. So the inconsistency appears more often.

So, Iā€™ve been using that for some time now [ā€¦] and everything seems fine [ā€¦]

The ā€œclip every windowā€ approach can be problematic even without discussing implementation details.

One big problem is that itā€™s difficult to style things properly. The window can have borders, shadows, or other styles, both inside and outside the perceived window border. If you simply clip the corners you would get bugs like: Window borders are covered up by rounded corners Ā· Issue #9 Ā· yilozt/mutter-rounded Ā· GitHub.

Your odds are better if windows borders are drawn by the window manager (known as SSD), but (1) if thereā€™s any border inside the window you will still get a visual bug, and (2) there will always be windows not decorated by the window manager.

Another problem is that, since the app has not been developed or tested with this clipping in mind, it can very much cause content to be partially or entirely obscured.

So, is there any plan for the gnome devs to carry this upstream?

Thereā€™s some interest in this at least from one of the designers, Tobias Bernard. Source: Round all window corners (#3476) Ā· Issues Ā· GNOME / gtk Ā· GitLab

Because the mutte-rounded implementation seemed quiet solid to me(except for the mentioned issue).

Bugs alone would prevent it from being upstreamed. And it will be very hard, if not downright impossible, to do this without bugs.

While ideally all windows should be consistently rounded, itā€™s just not a good idea to force it at the window manager level. The bottom line is that if you want consistency then you must ensure it when writing your app, either by using the same toolkit, or by otherwise emulating its appearance. It canā€™t be done by forcibly altering the behavior of apps at runtime.

3

Thanks for your well explained and detailed reply! I now clearly understand how forcefully rounding the corners on a window-manager level can be a bad idea.

I donā€™t think thatā€™s true. macOS and Windows donā€™t clip corners on all windows, either. The corners are rounded using their native toolkits[ā€¦]

But I disagree on this, given my experience with different toolkits on both Windows and MacOS. In my experience, Iā€™ve noticed that both Windows and MacOS clip corners off all windows drawn using gtk, electron or even flutter. Now, I have not tested any qt apps in those environments, but I doubt that the results would be any different.

Also I am not sure how this is done under the hood as their respective window managers draw a header bar on top of the windows using their native ui-toolkit; just like in gnome and kde, so am unsure if the same happens in the bottom using a footer, but that seems unlikely.

Anyways, thanks for investing your time in this discussion, being a newbie helps me learn a lot!

4

All of these draw their own decorations, so it has nothing to do with what native toolkits do.

5

In my experience, Iā€™ve noticed that both Windows and MacOS clip corners off all windows drawn using gtk, electron or even flutter.

Like I said, I believe thatā€™s just those toolkits using the native APIs under the hood to draw the window, or, more rarely, they may have used some other method to mask the corners to mimic the native look.

And thatā€™s also true on GNOME. Many apps/toolkits either use GTK directly or use some parts of it to emulate the appearance. I donā€™t think itā€™s any different from other platforms from a technical point of view.

1 Like
6

That might just be it, Thanks again!

And I hope someday we will get similar consistency in app uiā€™s in Gnome as in other osā€™es.

1 Like
7

im not sure if its actually just electron, flutter etc drawing windows 11 rounded corners. apps like firefox and such are also being rounded, and every game ive tried, old or new, has had rounded corners, its pretty obvious that its windows 11 itself doing the rounding

1 Like
8

Curently Mutter doesnā€™t do that, rather the app itself (using Hdy/Adw) does it. This could change, though.

9

Exactly! Even Mac OS has been doing this since ages!

10

I really hope hat they find a suitable implementation for that. Are you a gnome dev tho?

11

I donā€™t develop GNOME Shell or Mutter. What I can tell you, is that on Mac the toolkit requires window rounding (whereas GNOME supports multiple toolkits). Even in elementary, rounding is done by the apps.

12

It doesnā€™t clip windows on compositor side and never did. AppKit clips apps, like GTK does. And it even allows to disable the clipping, and some apps do that, e.g. Parallels: http://cdn.arstechnica.net/wp-content/uploads/2016/08/Parallels-Toolbox.jpg

1 Like
13

So you mean to say, each third party ui toolkit has to integrate with appkit on mac os in one way or another so that appkit can enforce some of its default widget descreption? Hmm interesting. That might explain a lot actually. But what do you think about windows 11ā€™s approach to it? As per my knowledge, they dont have a proper strict way to enforce these stuff on third-party toolkits.

14

(whereas GNOME supports multiple toolkits)

Doesnā€™t Mac support multiple toolkits too?

15

Yes, they usually use a regular NSWindow, same as e.g. Flutter uses a GtkWindow on Linux. GTK does too btw.

Windows 11? I mean youā€™ll clip apps not meant to be clipped this way. E.g. imagine a scrollbar with a stepper clipped by a round cornerā€¦ Not exactly a stretch, and I mean we had to redesign scrollbars in libadwaita to change border-radius from 8px to 12px to avoid this:

Screenshot from 2022-02-22 17-00-47

(this is webkit, itā€™s still using the older scrollbar style for now)

Changing it from 0px (without telling apps) is even more invasive.

2 Likes
16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.