| >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. |
> 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.