7 ms·

> Whereas, on Linux Wayland, if you want to support GNOME If you want to support GNOME, you use GTK or use a library that interfaces with GTK. The binary comp

> Whereas, on Linux Wayland, if you want to support GNOME If you want to support GNOME, you use GTK or use a library that interfaces with GTK. The binary compatibility with other desktops is just a "nice thing" to have, but GNOME really doesn't care for apps not made for GNOME. There was a project where Qt would interface with GTK and let GTK handle its window management (similar to macOS/Windows), rather than dealing directly to the display server, but I think its dead.

chrismorgan 4y ago
> but GNOME really doesn't care for apps not made for GNOME And this is the sabotage of GTK and the Linux desktop that I’m speaking of.
- hutzlibu 4y ago
  But there is a great difference between not caring and sabotage. Not caring is passive neglect, maybe not nice, yes. But sabotage is activly disturbing something with evil intentions. So this is a strong accusation, for which I like to see some more solid evidence, to believe it.
  - chrismorgan 4y ago
    It’s the co-opting of GTK that drives that. GTK used to be fairly platform-neutral under Linux, and at least moderately neutral on other operating systems, adopting some of their conventions and with theme matching being possible. It has become increasingly aggressively GNOME-bound, so that with every major release it becomes more and more difficult to produce anything that looks or feels native on any platform other than GNOME. (Even under Linux; and it’s completely impossible to produce a good result for Windows any more.) Gutting theming. All but forcing a particular idiosyncratic form of overlay scrollbars. Insisting on client-side decorations and refusing almost to acknowledge the very existence of server-side decorations (in both GNOME Shell and GTK, from both ends). The list goes on, though these are probably the three biggest ones. From time to time they take a small step back (e.g. libadwaita) or present an apparent alternative (e.g. libdecor), but those options never work well, and I strongly suspect that, whether consciously or unconsciously, they’re just to try to placate the mobs. (libadwaita hasn’t gone anywhere near far enough, to the point where they might as well not have bothered: GTK is still riddled with mandatory GNOME HIG stuff that is strongly opposed to conventions on other platforms.) ’Tis said: never attribute to malice what can be adequately explained by incompetence. But malice learns to wear incompetence as a mask, and organisations weaponsise incompetence. I doubt that individual GNOME developers mean any malice. There may be no malice intended from any of the GNOME project leaders. But over the last few years I have steadily become convinced that cumulatively their actions and policies are active sabotage towards every last bit of the Linux desktop that isn’t GNOME.
    - PlutoIsAPlanet 4y ago
      > acknowledge the very existence of server-side decorations I'm pretty sure GTK supports server-side decorations.. GNOME does not however.
      - galangalalgol 4y ago
        Rhel 8 still allows x11 as an option, does that mean it won't be getting gnome updates? My business has decided to keep x11 for the foreseeable future. I don't mind at all, I use x forwarding a lot.
        mroche 4y ago
        GNOME lifecycles in RHEL differ from other, leading-edge distributions. GNOME rebases aren't just simple API/ABI compatible minor updates, and things can break in doing so, therefore RHEL engineering wants to do them sparingly. Granted with GNOME 3.x there were quite a few rebases in RHEL 7 and RHEL 8 to fix issues and growing pains. Feature and fix backports are the preferred method for updating GNOME in RHEL, rather than complete rebases. The Xorg Server has been deprecated in RHEL, but exists in both RHEL 8 and RHEL 9 and will be maintained in those distributions for the entirety of their lifespans. It will be removed in some future version of RHEL. X11 support is provided by XWayland.
      - chrismorgan 4y ago
        I may have worded it a little strongly (despite tempering it with the word “almost”), but hear me out. GTK will use SSD so long as you don’t customise the title bar. I think you can even query it, with effort (gdk_wayland_display_prefers_ssd, c.f. https://gitlab.gnome.org/GNOME/gtk/-/commit/f2adaba237519642b88ccb42b47a95cf539a2a12 https://gitlab.gnome.org/GNOME/gtk/-/commit/f2adaba237519642...), and thus behave differently depending on compositor preference. (But even that is mildly nerfed from the org_kde_kwin_server_decoration_manager interface, since it only exposes “prefers SSD” and not “supports SSD”—though in practice I suspect there’s no difference in any compositor.) But guess what? GTK 4 has regressed matters in this space. Fancy that. If I run gtk3-demo, as a tiled window it gets Sway SSD and an app header bar which duplicates the title (fine), but it doesn’t have the window border or shadow (good). When I float the window, it gets border (including top radii) and shadow. This is well-behaved software, not acting quite how I’d prefer it to (I want SSD even floating, even double-title-barring), but still reasonably. But gtk4-demo? It gets border and shadow (drawing outside its designated area even in tiling mode, and I’m not sure why it’s possible for it to do that) regardless of whether it’s floating or not. Progress. They’re forging ahead with ignoring the existence of SSD as far as possible even in GTK.
samus 4y ago
This is a valid take, but it further fragments the Linux desktop. There are already too many different standards and technologies and transitions going on. Some of them for good reasons admittedly. Desktops only being compatible with their closely aligned toolkit is the last thing we need.

chrismorgan 4y ago

> but GNOME really doesn't care for apps not made for GNOME And this is the sabotage of GTK and the Linux desktop that I’m speaking of.

hutzlibu 4y ago
But there is a great difference between not caring and sabotage. Not caring is passive neglect, maybe not nice, yes. But sabotage is activly disturbing something with evil intentions. So this is a strong accusation, for which I like to see some more solid evidence, to believe it.
- chrismorgan 4y ago
  It’s the co-opting of GTK that drives that. GTK used to be fairly platform-neutral under Linux, and at least moderately neutral on other operating systems, adopting some of their conventions and with theme matching being possible. It has become increasingly aggressively GNOME-bound, so that with every major release it becomes more and more difficult to produce anything that looks or feels native on any platform other than GNOME. (Even under Linux; and it’s completely impossible to produce a good result for Windows any more.) Gutting theming. All but forcing a particular idiosyncratic form of overlay scrollbars. Insisting on client-side decorations and refusing almost to acknowledge the very existence of server-side decorations (in both GNOME Shell and GTK, from both ends). The list goes on, though these are probably the three biggest ones. From time to time they take a small step back (e.g. libadwaita) or present an apparent alternative (e.g. libdecor), but those options never work well, and I strongly suspect that, whether consciously or unconsciously, they’re just to try to placate the mobs. (libadwaita hasn’t gone anywhere near far enough, to the point where they might as well not have bothered: GTK is still riddled with mandatory GNOME HIG stuff that is strongly opposed to conventions on other platforms.) ’Tis said: never attribute to malice what can be adequately explained by incompetence. But malice learns to wear incompetence as a mask, and organisations weaponsise incompetence. I doubt that individual GNOME developers mean any malice. There may be no malice intended from any of the GNOME project leaders. But over the last few years I have steadily become convinced that cumulatively their actions and policies are active sabotage towards every last bit of the Linux desktop that isn’t GNOME.
  - PlutoIsAPlanet 4y ago
    > acknowledge the very existence of server-side decorations I'm pretty sure GTK supports server-side decorations.. GNOME does not however.
    - galangalalgol 4y ago
      Rhel 8 still allows x11 as an option, does that mean it won't be getting gnome updates? My business has decided to keep x11 for the foreseeable future. I don't mind at all, I use x forwarding a lot.
      - mroche 4y ago
        GNOME lifecycles in RHEL differ from other, leading-edge distributions. GNOME rebases aren't just simple API/ABI compatible minor updates, and things can break in doing so, therefore RHEL engineering wants to do them sparingly. Granted with GNOME 3.x there were quite a few rebases in RHEL 7 and RHEL 8 to fix issues and growing pains. Feature and fix backports are the preferred method for updating GNOME in RHEL, rather than complete rebases. The Xorg Server has been deprecated in RHEL, but exists in both RHEL 8 and RHEL 9 and will be maintained in those distributions for the entirety of their lifespans. It will be removed in some future version of RHEL. X11 support is provided by XWayland.
    - chrismorgan 4y ago
      I may have worded it a little strongly (despite tempering it with the word “almost”), but hear me out. GTK will use SSD so long as you don’t customise the title bar. I think you can even query it, with effort (gdk_wayland_display_prefers_ssd, c.f. https://gitlab.gnome.org/GNOME/gtk/-/commit/f2adaba237519642b88ccb42b47a95cf539a2a12 https://gitlab.gnome.org/GNOME/gtk/-/commit/f2adaba237519642...), and thus behave differently depending on compositor preference. (But even that is mildly nerfed from the org_kde_kwin_server_decoration_manager interface, since it only exposes “prefers SSD” and not “supports SSD”—though in practice I suspect there’s no difference in any compositor.) But guess what? GTK 4 has regressed matters in this space. Fancy that. If I run gtk3-demo, as a tiled window it gets Sway SSD and an app header bar which duplicates the title (fine), but it doesn’t have the window border or shadow (good). When I float the window, it gets border (including top radii) and shadow. This is well-behaved software, not acting quite how I’d prefer it to (I want SSD even floating, even double-title-barring), but still reasonably. But gtk4-demo? It gets border and shadow (drawing outside its designated area even in tiling mode, and I’m not sure why it’s possible for it to do that) regardless of whether it’s floating or not. Progress. They’re forging ahead with ignoring the existence of SSD as far as possible even in GTK.

samus 4y ago

This is a valid take, but it further fragments the Linux desktop. There are already too many different standards and technologies and transitions going on. Some of them for good reasons admittedly. Desktops only being compatible with their closely aligned toolkit is the last thing we need.