[h_anna_h]

> I don't want that when I'm making apps. If I'm making a GTK app then I would expect to get the GTK borders. If I'm making a Qt app then I would expect to get the Qt borders. And so on.

Surely the choice should fall on the user.

> That's a good way to ensure you get conflicting gestures/keybinds, inconsistent theming, and just a general lack of consistency.

Which is why we would like all of these to be configurable.

> The common ground would be drawing your own decorations because that's the way any Wayland server works by default

What if I, as a user of a tiling wm don't want any decorations?

> Xdg-decoration is an optional extension

That everything supports it afaik. (except mutter?)

[BrightGlow]

>Surely the choice should fall on the user.

It does, the user can choose to use GTK or Qt apps.

>Which is why we would like all of these to be configurable.

So making it all configurable is just guaranteeing that the app is broken out of the box and needs to have all this stuff set up before it even works correctly. Not exactly a user-friendly way to ship a program.

>What if I, as a user of a tiling wm don't want any decorations?

You may have to accept that some apps are not built to work in a tiling WM. In my experience, you will have a lot of trouble with some apps for various other reasons too, not just the decorations.

>That everything supports it afaik. (except mutter?)

I'm confused, you said everything supports it, but then immediately listed something that didn't support it.

[h_anna_h]

> It does, the user can choose to use GTK or Qt apps.

That's... not what I meant by it. I find this dangerous as it encourages duplicate work for minor differences.

I would rather not have to make both a GTK and a Qt version of my program just so my users can have the ability to do some basic customization.

> So making it all configurable is just guaranteeing that the app is broken out of the box

Not sure why you think that. You just put the existing choices as the defaults.

> You may have to accept that some apps are not built to work in a tiling WM

What about my apps then? As a programmer I want my programs to be friendly for both tiling and non-tiling WMs. This by itself excludes gtk as an option for me.

As for some apps not built to work in tiling WMs, the changes needed to make them work properly are usually extremely minor. To be honest it feels like the GNOME team is going out of their way to degrade the usability of their apps (and apps using gtk) for tiled WMs.

> In my experience, you will have a lot of trouble with some apps for various other reasons too

Some apps might have some minor issues that can usually be solved without a lot of effort, but even if they are not they don't usually pose any problem.

> I'm confused, you said everything supports it, but then immediately listed something that didn't support it.

Yes? Everything except mutter supports it as far as I know. Is there something difficult to understand here?

Edit: I heard that Enlightenment does not support it either.

[BrightGlow]

>I find this dangerous as it encourages duplicate work for minor differences. I would rather not have to make both a GTK and a Qt version of my program just so my users can have the ability to do some basic customization.

Sure, but this fragmentation isn't exactly new. There have always been multiple toolkits on Linux. I don't know what else to tell you, if you don't like it then you can pick one toolkit for your own apps and just focus on that. I wouldn't exactly call this "basic customization" if it requires you to rewrite your whole app so it's fine to just use one toolkit. I understand maybe you are facing some indecision about toolkits, that's normal, you may want to take some time to research them and find which one suits your app better.

>Not sure why you think that. You just put the existing choices as the defaults.

I already explained it, that will be broken if you use it outside the recommended environment as the HIGs won't match. The defaults only make sense on the target platform.

>What about my apps then? As a programmer I want my programs to be friendly for both tiling and non-tiling WMs. This by itself excludes gtk as an option for me.

Well, no it doesn't. You can disable the decorations in GTK. Most GTK apps don't by convention but you can do it if you really want. And you don't have to use GTK, you could use another toolkit.

>As for some apps not built to work in tiling WMs, the changes needed to make them work properly are usually extremely minor.

>Some apps might have some minor issues that can usually be solved without a lot of effort, but even if they are not they don't usually pose any problem.

I disagree with this entirely, the app needs to be designed in a fully responsive fashion to do that. Most older apps aren't like this.

>To be honest it feels like the GNOME team is going out of their way to degrade the usability of their apps (and apps using gtk) for tiled WMs.

I don't know what you mean by this. GNOME is not a tiling WM, so people who make GNOME apps usually do not target tiling WMs or test there. It would actually be the opposite, supporting the tiling WM would be going out of their way.

>Yes? Everything except mutter supports it as far as I know. Is there something difficult to understand here?

The way you're phrasing is confusing. To me it's like saying "every vehicle has four wheels except bicycles". Well I guess you could say that for some subset of vehicles, but I don't understand what the distinction here is supposed to be, or why that even matters.

[h_anna_h]

> Sure, but this fragmentation isn't exactly new. There have always been multiple toolkits on Linux

I think that we got a little bit sidetracked. "I want my users to be able to be able to select what borders to have" -> "the user can choose to use GTK or Qt apps" -> "it encourages duplicate work for minor differences" -> "fragmentation isn't exactly new"

Fragmentation might not be new but I would really rather not re-write my UI in another toolkit just to offer a second border option.

> that will be broken if you use it outside the recommended environment as the HIGs won't match

Depends on your definition of broken I guess. If you consider the user unbinding C-q from "quit" as broken because "the HIGs won't match" then I would have to say that I disagree. If the user wants to make "breaking" chances to my applications they should be free, especially since I don't believe that any big issues will be caused. If some minor issues are caused at certain configurations then that's fine, after all the user could revert to the default config if they encounter an issue that breaks their use-case or makes the interaction feel inferior to the default one.

> Well, no it doesn't

Thank you for the correction, I take it back. I guess if I go with gtk4 I would have to use a mix of gtk4+libdecor in order to have "native" borders in all WMs, is that correct?

> Most older apps aren't like this.

What do you mean by "older apps"? Motif-era, gtk2-era, or gtk3-era? I do not think that I had a big issue with any of them but I could be forgetting something.

> GNOME is not a tiling WM

Well, yeah, because GNOME is not a WM :p

By "going out of their way" I meant specifically the decision to implement CSD.

In general I think that GNOME should be able to do whatever it wants, I just wish that they would play better with the other players (and well, the users).

> The way you're phrasing is confusing. To me it's like saying "every vehicle has four wheels except bicycles". Well I guess you could say that for some subset of vehicles, but I don't understand what the distinction here is supposed to be, or why that even matters.

More like "all (relevant) C compilers except MSVC support C99 VLAs", or "all mobile phones in the EU except apple's use a standard charger". The point is that while xdg-decoration might be an optional extension in reality it is pretty much standard except in two WMs that require special handling.

[BrightGlow]

>Fragmentation might not be new but I would really rather not re-write my UI in another toolkit just to offer a second border option.

Then don't offer that second option? You can also offer multiple border options within the toolkit.

>If you consider the user unbinding C-q from "quit" as broken because "the HIGs won't match" then I would have to say that I disagree.

That would be one keybind. Complex apps have many keybinds, it's not really feasible to expect every user to change them all to match whatever their setup is. You could provide this as an option if you really wanted but some applications won't bother with this.

>If the user wants to make "breaking" chances to my applications they should be free, especially since I don't believe that any big issues will be caused.

Again you could provide this as an option if you really wanted but this is a sub-par experience for the user to have to mess with this. What I see really complex cross-platform apps doing: they just decide which platforms they support and then provide different sets of keybinds for each of those platforms, no need for the user to have to re-configure hundreds of keybinds to match their setup.

>I guess if I go with gtk4 I would have to use a mix of gtk4+libdecor in order to have "native" borders in all WMs, is that correct?

No, you cannot use libdecor with GTK4 at this time because of technical limitations. GTK4 technically does support the kde server decoration protocol which is an older version of xdg-decoration. So that may already work if you're using a wayland server that supports it. Otherwise you could try to patch GTK4 to support xdg-decoration.

>What do you mean by "older apps"? Motif-era, gtk2-era, or gtk3-era?

I've noticed many apps that are built around the old-style desktop concepts of menus/toolbars/panels/dialogs don't play well with the extremely squashed resolutions that tiling window managers tend to put windows into. This is the same problem with trying to run those "native" apps on a Linux phone like the Librem, they just aren't designed to run at a small resolution.

>Well, yeah, because GNOME is not a WM :p

Sorry, what I mean is that GNOME includes its own WM and shell which is the only thing that it supports, and that is the only thing that GNOME developers usually test with. They have not supported alternate WMs in quite a while, as they have no reason to.

>By "going out of their way" I meant specifically the decision to implement CSD.

Well that's not true, you can see some of the motivations for using CSD here: https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/

You may not agree with these motivations, but they were not done to make you miserable. Please don't assume bad faith.

>I just wish that they would play better with the other players (and well, the users).

I'm not sure what you mean, GNOME is its own platform. If you are not a user of that app platform then I don't see why it would matter to you.

>The point is that while xdg-decoration might be an optional extension in reality it is pretty much standard except in two WMs that require special handling.

There's no special handling, everything that is needed to support xdg-decoration is also needed to support those other WMs. Even with xdg-decoration, you still need to provide a fallback. Also, I believe Weston is another one that does not support it, and the Elementary compositor is likely not going to support it either.

[smoldesu]

I frankly cannot agree with most of the stuff that you are presenting as fact here. I understand that you use GNOME and are passionate about it, but your insistence on right and wrong answers is absolutely not what drives the Linux community. If there were easy solutions, we would have built a perfect operating system 40 years ago and quit arguing then and there.

> Again you could provide this as an option if you really wanted but this is a sub-par experience for the user to have to mess with this.

Then don't make them. Just do what every other desktop has done since 1992, give people the option to configure things the way they want, and save your "sub-par user experience" argument for setting the defaults. If corner-cutting starts to affect power users, you need to go back to the drawing board and re-think things. Luckily, this is a pretty easy situation: nothing is broken, nothing needs to be fixed. It's along the lines of GNOME deciding the remove your clipboard history because it was gauche and such an old and ugly feature.

> Well that's not true, you can see some of the motivations for using CSD here

Yeah, real motivation going on there. Of the 4 apps they mention needing CSD, only one got it. Is that really what 3 years of progress should look like for that kind of initiative?

> I'm not sure what you mean, GNOME is its own platform. If you are not a user of that app platform then I don't see why it would matter to you.

GNOME is not Linux, and the issue is that the GNOME developers are making too many decisions on behalf of the end user. I didn't have an issue with the mostly hands-off approach that GTK2 and 3 used. I do take issue when I can't use a desktop environment because my preference for handling packages is apparently verboten, and now they've decided to remove features that I liked. It's a regression on the level of dropping the Unity desktop, but even more user-hostile.

And even still, I have a hard time calling GNOME in it's current state much of a platform. It exhibits constant crashing issues on my Haswell devices which means I can't use it on half my devices, and it only truly functions on one or two distros. Not to go "us vs them", but KDE has no problem maintaining a stable, usable desktop even across major releases. I'm utterly dumbfounded by how the current maintainers of GNOME feel so self-righteous in their redesign, especially considering the state of their recent releases.