16 ms·

> Gnome-shell has decided not to support server side decorations I still can’t understand this at all. It’s such obvious and complete folly. And it’s not an is

> Gnome-shell has decided not to support server side decorations I still can’t understand this at all. It’s such obvious and complete folly. And it’s not an isolated decision; there are quite a few related places where it is very apparent that GNOME has co-opted GTK and been actively sabotaging it for anyone that’s not GNOME, and it’s been heavily poisoning the Linux desktop space. (Note that I’m not railing against client-side decorations, though the current free-for-all with no way of signalling even the simplest of conventions like the expected location of window controls (even apart from their appearance) is quite insane; I’m complaining about not supporting server-side decorations, since they are fundamental to some window managers (e.g. Sway) and completely sensible for many apps. The existence of “fallback client-side decorations” and the loose requirement that every app implement this thing that it often has no need of and can’t do as well as the window manager is at least moderately absurd.)

vetinari 4y ago
X11 was the only environment that did server side decorations. Both win32 and macos draw decorations client-side. Even if you don't handle the respective messages in your event loop, the libraries that you linked to, do. Server-side decorations are hard. You cannot properly synchronize two processes to draw perfect frame. When a single process is responsible, it is easy.
- jstimpfle 4y ago
  > You cannot properly synchronize two processes to draw perfect frame. Not taking sides, but why do you need to synchronize two processes when one should only draw a frame and the other should only draw the contents?
  - fvdessen 4y ago
    When you resize the window, both the frame and the content should be resized and rendered at the same time, otherwise you have gaps or clipped content
    - jstimpfle 4y ago
      There could be the same problem outside of a window given that most windows are rendered by separate processes. Unless there is a compositor, which I think there is? And can that problem you mention not be avoided using a compositor?
    - kaba0 4y ago
      I don’t know, if I resize the window I do want the border to reflect the changes even if the app froze, and drawing a black rectangle with a frame and optionally drawing the ready frame made by the app onto it doesn’t sound too hard to me.
      - dzaima 4y ago
        Most of the time, though, you run applications that aren't frozen. Sure, having resizing do something in that case is useful, but you don't want those black bars to appear for the fraction of time between moving your mouse & the application redrawing, for every single frame of window resizing where the app didn't redraw in time (text reflowing, graphics initialization & other re-computation can often push resizing frame times above the 16ms of 60fps). (X11 and its server-side decorations appear to be able to handle this as-is - decoration redrawing is delayed until either the application redraws, or some timeout (iirc around a second or two?), at which point you get the ugly black bars)
    - chrismorgan 4y ago
      Good reading on this issue: https://raphlinus.github.io/rust/gui/2019/06/21/smooth-resize-test.html https://raphlinus.github.io/rust/gui/2019/06/21/smooth-resiz...
    - badsectoracula 4y ago
      This sounds like Wayland Weirdness. On Xorg with Window Maker and no (desktop) compositor running, my own toolkit (example app[0]) resizes instantly. On Xorg with KDE5 (not sure which exactly version, whatever openSUSE has) and a (desktop) compositor enabled, same toolkit also resizes without gaps (though there is a small delay, probably due to the compositor, i didn't try without it). Same with native apps. On Wayland/KDE5 the same toolkit resizes without gaps but there is a visible "lag" for the titlebar to be updated that didn't exist with Xorg/KDE5. Since the toolkit only supports X11 i'm not sure if it is due to XWayland or KDE5 though. TBH in none of the above configurations that'd be something i'd notice unless i was looking for it - or it was very laggy. Even on Wayland, it is something i noticed because i was resizing the window constantly back and forth to see if there is any lag. [0] https://i.imgur.com/00Y3kZi.png https://i.imgur.com/00Y3kZi.png
- sph 4y ago
  > Both win32 and macos draw decorations client-side. That's technically true but misleading. Yes, they have client-side decorations, but also a single and unified UI toolkit all applications use. So effectively _you_, the application writer, do not have to care about decorations. Whereas, on Linux Wayland, if you want to support GNOME, _you_ have to care about decorations, or you have no titlebar nor X button. Which means you need to link against libdecor yourself to get that functionality and in theory wouldn't be that bad if that library was maintained and functional, but it isn't. The one stable tag is 0.1.0 from one year ago, and it still causes massive lag when trying to resize a window if you have more than 1x scaling: https://gitlab.gnome.org/jadahl/libdecor/-/issues/37 https://gitlab.gnome.org/jadahl/libdecor/-/issues/37 — Don't be mislead by the title, affects AMD as well. libdecor is the _only_ way to have decorations on Wayland on all major DEs, unless you actually want to write the entire decoration code yourself. And it's buggy and unmaintained. And, cherry on top, libdecor does not match the desktop environment's look and feel, so your app has decorations that look completely out of place. I'm a GNOME and Wayland apologist, but libdecor is terrible, unavoidable, and exists only because GNOME couldn't pull their head out of their arse and created this situation. Not supporting server-side decorations is only a good idea in a vacuum, not in the real world. Applications should be able to choose whether they care about it (i.e. Firefox for their UI), or not at all (i.e. a video game window), as it's possible to do in Windows or macOS.
  - PlutoIsAPlanet 4y ago
    > 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.
- garaetjjte 4y ago
  >win32 Are you sure about this? How would things like appending "Not responding" to title bar work?
  - PlutoIsAPlanet 4y ago
    It's a separate event loop from your application.
    - account42 4y ago
      Or in other terms, a hack to work around the limitations of CSDs which MS is stuck with. We don't need to copy their mistakes.
- chrismorgan 4y ago
  I think you may be trying to draw a technical distinction which misses the point of what people mean by “client-side decorations” and “server-side decorations”. Win32 has always defaulted to server-side decorations, by which we mean that the window manager controls the rendering, appearance and functionality of the title bar. Maybe this is actually run in client space via user32.dll or whatever as part of the OS-managed event loop, but functionally your app gets told “here, have a client area” (and isn’t that name telling!) and works inside that and completely ignores the remainder of the window area, and the window decorations implementation is provided by the window manager, so that theme changes (ancient Classic, XP Luna, recent Classic, Aero Glass, Modern, colours within each, &c. &c.) immediately apply globally. This is what people mean by server-side decorations. They mean what is still the default under Win32 and I presume macOS, even if on both platforms it’s not the recommended style any more for most apps. But it’s also worth noting that the recommended client-side decorations style on Win32 at least (don’t know much about macOS) is still guided by window manager stylistic conventions, including theme colours where possible.
  - PlutoIsAPlanet 4y ago
    Two different things here. In the Wayland/Xorg world, server-side decorations means its drawn by the compositor or display server, neither macOS or Windows do this. Windows is a lot more complicated, the decorations are drawn by the client... but that client is part of the userspace dll from the system you link to in your app and gives you a handle to draw on. macOS the only documented method to draw afaik is through Cocoa which can give you a space to draw on, but the linked Cocoa library will still draw your apps window. To the user, I guess SSD achieve the same thing as Windows/macOS do, but with very different methods because unlike macOS and Windows, there's no central toolkit/library.
- flohofwoe 4y ago
  Huh? When I create a window on macOS, Windows or X11, I get a decorated window, and that's the only point that matters. Where this decoration is drawn within the operating system's window system is nothing the API user needs to or should worry about.
- phkahler 4y ago
  Most user interactions with window decorations need to be handled server-side. Server side also makes sense because the compositor and the DE are basically the same under Wayland, so things like themes should be implemented once server-side and applications wouldn't have to do anything to change their frame to match.
- LtWorf 4y ago
  > X11 was the only environment that did server side decorations. > Both win32 and macos draw decorations client-side Which is why on linux if a process freezes I can kill it by pressing the normal X on the window, while on other operating systems I need to open the process manager.
  - AshamedCaptain 4y ago
    And you'll also note that if a win32 process freezes (i.e. stops replying to wm messages in a timely fashion), the win32 window manager will take over drawing the window decoration, so that you can also kill the process by pressing the normal X close button on the window. At least since XP times.
    - account42 4y ago
      Right, which makes using the bUt wInDowS UsEs CsDS argument against SSDs especially silly. Even MS found that CSDs have usability problems but are stuck with them so have to hack around the limitations - and even then there will still be a time where you can't even move the window before the SSD hack takes over.
  - deleted 4y ago
    [deleted]
- yxhuvud 4y ago
  It is easy until you have to support the look and feel of two different server side environments.
- marcodiego 4y ago
  I remember an old post years ago on DOSBox forum. Someone posted a patch to update the number of FPS on the window titlebar. Someone else tried it came back complaining that it ate the processor. A bit of investigation revealed how expensive it was to update the titlebar: DOSBox, in some form, notified the DE (window manager) that the titlebar needed update; then the window manager informed the window decorator about the update; it then updated the titlebar and notified X11 to redraw it; X11 then had to sync all that to post new screen with everything ready to show. Now, go back and count the number of processes and calculate how many context switches were required just to update the titlebar. Server-side decoration made things more modular because it allowed the window decorator to be an entirely independent process. It could allow to use Beryl or kwin or any other window decorator with compiz, for example. Even considering these advantages, the price one paid for it was too expensive to justify. X11 did it, basically nobody else did; certainly for a good reason. Server-side decoration is one thing I'm glad we are finally getting rid of.
bzzzt 4y ago
By that logic "not supporting" equals "actively sabotaging"? I'm no Gnome developer, but the OSS landscape is fragmented enough as is and the number of developers is very limited, so not supporting something that does not help your project looks excusable. It hasn't stopped Blender from supporting Wayland in this case anyway.
- tinus_hn 4y ago
  Blender is not using GTK for that so those things have nothing to do with each other.
- dzaima 4y ago
  The discussion[0] pretty explicitly says that support isn't planned, so it's not just that there is a lack of developers. Either way, I would assume that the effort needed to add server-side decorations to GNOME would be way less than the combined effort of having every single GUI toolkit & program directly using Wayland needing to draw their own decorations (in addition to resulting in a better end-user experience of having native decorations everywhere). [0]: https://gitlab.gnome.org/GNOME/mutter/-/issues/217 https://gitlab.gnome.org/GNOME/mutter/-/issues/217
- chrismorgan 4y ago
  The sabotaging I speak of is in other things too; this is just the proximate example of their entire approach which began destructive through negligence, but seems to have become weaponised somewhere along the way so that although I doubt any involved intend malice, they have become complicit in organisational malice: because GNOME is not the only player in the space, but they’ve tried to take it over and are doing harm to everything else with their policies. In this case: they’ve taken something that used to work across the board under X, and which is still used extensively, and for which there have been a number of well-reasoned pleas, and actively removed it by refusing to implement it under Wayland, although it should be fairly straightforward to do and is required for a parity that a great many apps and users desire and some apps need, and although not doing it forces apps that don’t (perhaps can’t) use GTK and don’t need client-side decorations to produce worse results. (And requiring GTK is nasty for non-GNOME apps anyway.)
- 4y ago
bitwize 4y ago
Everybody has agreed that client-side decorations are the correct solution.
- tsukurimashou 4y ago
  I'm pretty sure you wouldn't be having this conversation if that was the case
sprash 4y ago
It's obvious sabotage. Don't ever use GNOME, don't use GNOME software, don't contribute to GNOME projects, don't go to their conferences and don't ever give them money.
- Gigachad 4y ago
  Don’t care. I think client side decorations is a good idea and I like gnome software.
  - abenga 4y ago
    Right? I find the "I don't like GNOME, so no one should" attitude extremely patronising.
oliwarner 4y ago
GNOME has spent a decade pushing CSD and CSD-enabled ideas like the titlebar buttons and menus you see in many core GNOME apps. It's not surprising they're in no rush to throw that out.
- abeyer 4y ago
  Meanwhile GNOME users have spent that decade decrying the awful results... typical GNOME UI design approach, I guess.
  - oliwarner 4y ago
    Absolutely, but it's GNOME's project to break. GNOME has the unenviable position where everybody wants to use it —cite: we are— but we all still love to bitch about it. If it were so bad, we'd have jumped ship, or stayed with Mate or Cinnamon or whatever the 2.x branch was called. I guess from our point of view, we feel a little like hostages and just because we don't like these changes, doesn't mean we want to migrate to another desktop; still, I cannot ignore that I'm paying nothing for the maintenance and development of this system and I'm not investing my time in its development or governance, so frankly who am I to say what should be what?
    - chrismorgan 4y ago
      But it wasn’t GNOME’s project—they took over maintenance of something that was used by many, and for many years maintained this trust, acting benevolently. But more recently (mostly from GTK+ 3 on) they have acted increasingly hostilely, thoroughly violating the trust placed in them by the community. And the way things have happened makes it very difficult to successfully fork it, quite similarly to Embrace, Extend, Extinguish theory (though in a somewhat different space). It’s made particularly hard by the fact that GTK+ 3 and GTK 4 each make deeply-interwoven good and bad changes, so forking from an earlier version would be a significant regression as well as a significant fix. Combine the general mutual incompatibilities and how deeply GTK is woven into apps, and forking becomes quite impractical.
    - abeyer 4y ago
yamtaddle 4y ago
Redhat-steered projects act an awful lot like they're trying to make it really hard to compete with Redhat without picking the same projects they do—so, being at their mercy, unless you have a lot of resources to maintain forks against a maybe-hostile upstream. Been like that at least since the whole Systemd thing. Maybe that's not what they're doing, but it sure looks like it. As a user I find this frustrating because I actually wouldn't mind some consolidation in Linux, especially in the GUI layers, but tend to hate RedHat's taste in these matters.
- traverseda 4y ago
  It is essentially the same "embrace, extend, extinguish" policy that microsoft used to use. The fact that the underlying code is open source apparently doesn't matter too much. If someone else did come up with a compelling alternative init system just make systemd a soft dependency of your desktop environment, and make sure that patching that out requires a lot of active maintenance and ongoing work.
  - deleted 4y ago
    [deleted]
  - 411111111111111 4y ago
    I never noticed they pulled the plug on systemd for the extinguish, when did they do that? And how exactly was any of it an embrace? Redhat was a Linux distribution provider from the start, they didn't take something over in order to destroy it. They just created systemd and provided help to distributions if they were willing to use it. The distributions were fully aware what they were doing when they abandoned Sysvinit, it wasn't a backhanded tactic by redhat. A recent example of something close to EEE is vscode, which is now getting "refactored" to utilize non-open source plug-ins for everything, effectively extinguishing it from a free perspective.
    - traverseda 4y ago
      That's not how EEE worked. From wikipedia 1. Embrace: Development of software substantially compatible with a competing product, or implementing a public standard. 2. Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the "simple" standard. 3. Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions. Systemd is part of "Extend", and what they're extending is the linux ecosystem. Sure, those extensions might make things better in the short term and for some uses cases, but they're now owned by IBM so good luck!
grandinj 4y ago
What you are seeing is a change in culture. X11 was very much a "everything is a work-in-progress" culture. Experiments were fine, clients and servers could support whatever they wanted, etc, etc. Wayland is an "opinionated" culture. Everything the core devs don't like is not allowed. Everything HAS to fit into the "every frame is perfect" mantra. Which is ridiculous over-engineering and disallows a large number of perfectly acceptable (to end users) use-cases.
- teawrecks 4y ago
  It's not worth driving away the vast majority of potential end users to cater to a small number of hackers through, even if the hackers were there first. When it comes to wide appeal, linux suffers from paradox of choice on multiple levels. But there are a huge number of people who want the stability of windows/mac/etc without the violation of privacy, as long as they don't have to spend ANY time configuring their system to keep it working. To them, just like fixing their car, that's someone else' job/hobby that they don't have time for or get any enjoyment from. I don't see any reason why Linux can't offer that experience, but only if we have a windowing stack that is very opinionated about the user experience. Maybe it's time for an X12, but the Valves out there trying to make a competitive experience on linux for consumers will be dumping their money into Wayland.
- Arnavion 4y ago
  >Wayland is an "opinionated" culture. Everything the core devs don't like is not allowed. False. If your use case is so important nothing prevents you from making your own protocol and implementing client and compositor support for it. It's exactly the same as X. (Note for those unfamiliar: I'm not saying "make a replacement for Wayland". Wayland is a collection of protocols that define one or more objects and the formats of their requests / responses / events. Showing windows is part of the xdg-shell protocol, etc.)
  - grandinj 4y ago
    yes, technically you can do that. But if you actually want to __use__ your extension/protocol with someone else, it needs to get accepted into various core libs and repositories. ....And then the gatekeepers step up and your problems start.
asoneth 4y ago
I think the Window Controls Overlay[1] approach that Microsoft is proposing for Progressive Web Apps on windows seems like an interesting compromise to solve some of the issues you raise. Specifically that the client code is allowed to customize _most_ of the headerbar, with the exception of an area reserved for the window controls (minimize, maximize, close, etc). It seems like this approach would still support alternate or tiling window managers as they could omit or provide custom window controls. [1] https://blogs.windows.com/msedgedev/2022/09/27/closing-pixel-gap-native-web-window-controls-overlay/ https://blogs.windows.com/msedgedev/2022/09/27/closing-pixel...
- chrismorgan 4y ago
  Very nice! I hadn’t heard of that. I’m amused at how exactly it matches my mullings of how I’d do it in a web tech stack (manifest field, env() variables, navigator property with events, CSS property to indicate draggable area), with only a couple of missing pieces: the ability to match the appearance of the native controls and native conventions (e.g. `background: env(titlebar-area-background); color: env(titlebar-area-color); text-align: env(titlebar-area-align)`, though for best results you’d still need a little more here and there). I’ve thought of trying to design something like this for Wayland server-side decorations or at least making a better replacement for libdecor, but it wouldn’t help me personally and it’s clear that GNOME isn’t having a bar of the entire approach, so I sadly just don’t think it’s worth the effort.
deleted 4y ago
[deleted]

vetinari 4y ago

X11 was the only environment that did server side decorations. Both win32 and macos draw decorations client-side. Even if you don't handle the respective messages in your event loop, the libraries that you linked to, do. Server-side decorations are hard. You cannot properly synchronize two processes to draw perfect frame. When a single process is responsible, it is easy.

jstimpfle 4y ago
> You cannot properly synchronize two processes to draw perfect frame. Not taking sides, but why do you need to synchronize two processes when one should only draw a frame and the other should only draw the contents?
- fvdessen 4y ago
  When you resize the window, both the frame and the content should be resized and rendered at the same time, otherwise you have gaps or clipped content
  - jstimpfle 4y ago
    There could be the same problem outside of a window given that most windows are rendered by separate processes. Unless there is a compositor, which I think there is? And can that problem you mention not be avoided using a compositor?
  - kaba0 4y ago
    I don’t know, if I resize the window I do want the border to reflect the changes even if the app froze, and drawing a black rectangle with a frame and optionally drawing the ready frame made by the app onto it doesn’t sound too hard to me.
    - dzaima 4y ago
      Most of the time, though, you run applications that aren't frozen. Sure, having resizing do something in that case is useful, but you don't want those black bars to appear for the fraction of time between moving your mouse & the application redrawing, for every single frame of window resizing where the app didn't redraw in time (text reflowing, graphics initialization & other re-computation can often push resizing frame times above the 16ms of 60fps). (X11 and its server-side decorations appear to be able to handle this as-is - decoration redrawing is delayed until either the application redraws, or some timeout (iirc around a second or two?), at which point you get the ugly black bars)
  - chrismorgan 4y ago
    Good reading on this issue: https://raphlinus.github.io/rust/gui/2019/06/21/smooth-resize-test.html https://raphlinus.github.io/rust/gui/2019/06/21/smooth-resiz...
  - badsectoracula 4y ago
    This sounds like Wayland Weirdness. On Xorg with Window Maker and no (desktop) compositor running, my own toolkit (example app[0]) resizes instantly. On Xorg with KDE5 (not sure which exactly version, whatever openSUSE has) and a (desktop) compositor enabled, same toolkit also resizes without gaps (though there is a small delay, probably due to the compositor, i didn't try without it). Same with native apps. On Wayland/KDE5 the same toolkit resizes without gaps but there is a visible "lag" for the titlebar to be updated that didn't exist with Xorg/KDE5. Since the toolkit only supports X11 i'm not sure if it is due to XWayland or KDE5 though. TBH in none of the above configurations that'd be something i'd notice unless i was looking for it - or it was very laggy. Even on Wayland, it is something i noticed because i was resizing the window constantly back and forth to see if there is any lag. [0] https://i.imgur.com/00Y3kZi.png https://i.imgur.com/00Y3kZi.png
sph 4y ago
> Both win32 and macos draw decorations client-side. That's technically true but misleading. Yes, they have client-side decorations, but also a single and unified UI toolkit all applications use. So effectively _you_, the application writer, do not have to care about decorations. Whereas, on Linux Wayland, if you want to support GNOME, _you_ have to care about decorations, or you have no titlebar nor X button. Which means you need to link against libdecor yourself to get that functionality and in theory wouldn't be that bad if that library was maintained and functional, but it isn't. The one stable tag is 0.1.0 from one year ago, and it still causes massive lag when trying to resize a window if you have more than 1x scaling: https://gitlab.gnome.org/jadahl/libdecor/-/issues/37 https://gitlab.gnome.org/jadahl/libdecor/-/issues/37 — Don't be mislead by the title, affects AMD as well. libdecor is the _only_ way to have decorations on Wayland on all major DEs, unless you actually want to write the entire decoration code yourself. And it's buggy and unmaintained. And, cherry on top, libdecor does not match the desktop environment's look and feel, so your app has decorations that look completely out of place. I'm a GNOME and Wayland apologist, but libdecor is terrible, unavoidable, and exists only because GNOME couldn't pull their head out of their arse and created this situation. Not supporting server-side decorations is only a good idea in a vacuum, not in the real world. Applications should be able to choose whether they care about it (i.e. Firefox for their UI), or not at all (i.e. a video game window), as it's possible to do in Windows or macOS.
- PlutoIsAPlanet 4y ago
  > 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.
garaetjjte 4y ago
>win32 Are you sure about this? How would things like appending "Not responding" to title bar work?
- PlutoIsAPlanet 4y ago
  It's a separate event loop from your application.
  - account42 4y ago
    Or in other terms, a hack to work around the limitations of CSDs which MS is stuck with. We don't need to copy their mistakes.
chrismorgan 4y ago
I think you may be trying to draw a technical distinction which misses the point of what people mean by “client-side decorations” and “server-side decorations”. Win32 has always defaulted to server-side decorations, by which we mean that the window manager controls the rendering, appearance and functionality of the title bar. Maybe this is actually run in client space via user32.dll or whatever as part of the OS-managed event loop, but functionally your app gets told “here, have a client area” (and isn’t that name telling!) and works inside that and completely ignores the remainder of the window area, and the window decorations implementation is provided by the window manager, so that theme changes (ancient Classic, XP Luna, recent Classic, Aero Glass, Modern, colours within each, &c. &c.) immediately apply globally. This is what people mean by server-side decorations. They mean what is still the default under Win32 and I presume macOS, even if on both platforms it’s not the recommended style any more for most apps. But it’s also worth noting that the recommended client-side decorations style on Win32 at least (don’t know much about macOS) is still guided by window manager stylistic conventions, including theme colours where possible.
- PlutoIsAPlanet 4y ago
  Two different things here. In the Wayland/Xorg world, server-side decorations means its drawn by the compositor or display server, neither macOS or Windows do this. Windows is a lot more complicated, the decorations are drawn by the client... but that client is part of the userspace dll from the system you link to in your app and gives you a handle to draw on. macOS the only documented method to draw afaik is through Cocoa which can give you a space to draw on, but the linked Cocoa library will still draw your apps window. To the user, I guess SSD achieve the same thing as Windows/macOS do, but with very different methods because unlike macOS and Windows, there's no central toolkit/library.
flohofwoe 4y ago
Huh? When I create a window on macOS, Windows or X11, I get a decorated window, and that's the only point that matters. Where this decoration is drawn within the operating system's window system is nothing the API user needs to or should worry about.
phkahler 4y ago
Most user interactions with window decorations need to be handled server-side. Server side also makes sense because the compositor and the DE are basically the same under Wayland, so things like themes should be implemented once server-side and applications wouldn't have to do anything to change their frame to match.
LtWorf 4y ago
> X11 was the only environment that did server side decorations. > Both win32 and macos draw decorations client-side Which is why on linux if a process freezes I can kill it by pressing the normal X on the window, while on other operating systems I need to open the process manager.
- AshamedCaptain 4y ago
  And you'll also note that if a win32 process freezes (i.e. stops replying to wm messages in a timely fashion), the win32 window manager will take over drawing the window decoration, so that you can also kill the process by pressing the normal X close button on the window. At least since XP times.
  - account42 4y ago
    Right, which makes using the bUt wInDowS UsEs CsDS argument against SSDs especially silly. Even MS found that CSDs have usability problems but are stuck with them so have to hack around the limitations - and even then there will still be a time where you can't even move the window before the SSD hack takes over.
- deleted 4y ago
  [deleted]
yxhuvud 4y ago
It is easy until you have to support the look and feel of two different server side environments.
marcodiego 4y ago
I remember an old post years ago on DOSBox forum. Someone posted a patch to update the number of FPS on the window titlebar. Someone else tried it came back complaining that it ate the processor. A bit of investigation revealed how expensive it was to update the titlebar: DOSBox, in some form, notified the DE (window manager) that the titlebar needed update; then the window manager informed the window decorator about the update; it then updated the titlebar and notified X11 to redraw it; X11 then had to sync all that to post new screen with everything ready to show. Now, go back and count the number of processes and calculate how many context switches were required just to update the titlebar. Server-side decoration made things more modular because it allowed the window decorator to be an entirely independent process. It could allow to use Beryl or kwin or any other window decorator with compiz, for example. Even considering these advantages, the price one paid for it was too expensive to justify. X11 did it, basically nobody else did; certainly for a good reason. Server-side decoration is one thing I'm glad we are finally getting rid of.

bzzzt 4y ago

By that logic "not supporting" equals "actively sabotaging"? I'm no Gnome developer, but the OSS landscape is fragmented enough as is and the number of developers is very limited, so not supporting something that does not help your project looks excusable. It hasn't stopped Blender from supporting Wayland in this case anyway.

tinus_hn 4y ago
Blender is not using GTK for that so those things have nothing to do with each other.
dzaima 4y ago
The discussion[0] pretty explicitly says that support isn't planned, so it's not just that there is a lack of developers. Either way, I would assume that the effort needed to add server-side decorations to GNOME would be way less than the combined effort of having every single GUI toolkit & program directly using Wayland needing to draw their own decorations (in addition to resulting in a better end-user experience of having native decorations everywhere). [0]: https://gitlab.gnome.org/GNOME/mutter/-/issues/217 https://gitlab.gnome.org/GNOME/mutter/-/issues/217
chrismorgan 4y ago
The sabotaging I speak of is in other things too; this is just the proximate example of their entire approach which began destructive through negligence, but seems to have become weaponised somewhere along the way so that although I doubt any involved intend malice, they have become complicit in organisational malice: because GNOME is not the only player in the space, but they’ve tried to take it over and are doing harm to everything else with their policies. In this case: they’ve taken something that used to work across the board under X, and which is still used extensively, and for which there have been a number of well-reasoned pleas, and actively removed it by refusing to implement it under Wayland, although it should be fairly straightforward to do and is required for a parity that a great many apps and users desire and some apps need, and although not doing it forces apps that don’t (perhaps can’t) use GTK and don’t need client-side decorations to produce worse results. (And requiring GTK is nasty for non-GNOME apps anyway.)
4y ago

bitwize 4y ago

Everybody has agreed that client-side decorations are the correct solution.

tsukurimashou 4y ago
I'm pretty sure you wouldn't be having this conversation if that was the case

sprash 4y ago

It's obvious sabotage. Don't ever use GNOME, don't use GNOME software, don't contribute to GNOME projects, don't go to their conferences and don't ever give them money.

Gigachad 4y ago
Don’t care. I think client side decorations is a good idea and I like gnome software.
- abenga 4y ago
  Right? I find the "I don't like GNOME, so no one should" attitude extremely patronising.

oliwarner 4y ago

GNOME has spent a decade pushing CSD and CSD-enabled ideas like the titlebar buttons and menus you see in many core GNOME apps. It's not surprising they're in no rush to throw that out.

abeyer 4y ago
Meanwhile GNOME users have spent that decade decrying the awful results... typical GNOME UI design approach, I guess.
- oliwarner 4y ago
  Absolutely, but it's GNOME's project to break. GNOME has the unenviable position where everybody wants to use it —cite: we are— but we all still love to bitch about it. If it were so bad, we'd have jumped ship, or stayed with Mate or Cinnamon or whatever the 2.x branch was called. I guess from our point of view, we feel a little like hostages and just because we don't like these changes, doesn't mean we want to migrate to another desktop; still, I cannot ignore that I'm paying nothing for the maintenance and development of this system and I'm not investing my time in its development or governance, so frankly who am I to say what should be what?
  - chrismorgan 4y ago
    But it wasn’t GNOME’s project—they took over maintenance of something that was used by many, and for many years maintained this trust, acting benevolently. But more recently (mostly from GTK+ 3 on) they have acted increasingly hostilely, thoroughly violating the trust placed in them by the community. And the way things have happened makes it very difficult to successfully fork it, quite similarly to Embrace, Extend, Extinguish theory (though in a somewhat different space). It’s made particularly hard by the fact that GTK+ 3 and GTK 4 each make deeply-interwoven good and bad changes, so forking from an earlier version would be a significant regression as well as a significant fix. Combine the general mutual incompatibilities and how deeply GTK is woven into apps, and forking becomes quite impractical.
  - abeyer 4y ago

yamtaddle 4y ago

Redhat-steered projects act an awful lot like they're trying to make it really hard to compete with Redhat without picking the same projects they do—so, being at their mercy, unless you have a lot of resources to maintain forks against a maybe-hostile upstream. Been like that at least since the whole Systemd thing. Maybe that's not what they're doing, but it sure looks like it. As a user I find this frustrating because I actually wouldn't mind some consolidation in Linux, especially in the GUI layers, but tend to hate RedHat's taste in these matters.

traverseda 4y ago
It is essentially the same "embrace, extend, extinguish" policy that microsoft used to use. The fact that the underlying code is open source apparently doesn't matter too much. If someone else did come up with a compelling alternative init system just make systemd a soft dependency of your desktop environment, and make sure that patching that out requires a lot of active maintenance and ongoing work.
- deleted 4y ago
  [deleted]
- 411111111111111 4y ago
  I never noticed they pulled the plug on systemd for the extinguish, when did they do that? And how exactly was any of it an embrace? Redhat was a Linux distribution provider from the start, they didn't take something over in order to destroy it. They just created systemd and provided help to distributions if they were willing to use it. The distributions were fully aware what they were doing when they abandoned Sysvinit, it wasn't a backhanded tactic by redhat. A recent example of something close to EEE is vscode, which is now getting "refactored" to utilize non-open source plug-ins for everything, effectively extinguishing it from a free perspective.
  - traverseda 4y ago
    That's not how EEE worked. From wikipedia 1. Embrace: Development of software substantially compatible with a competing product, or implementing a public standard. 2. Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the "simple" standard. 3. Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions. Systemd is part of "Extend", and what they're extending is the linux ecosystem. Sure, those extensions might make things better in the short term and for some uses cases, but they're now owned by IBM so good luck!

grandinj 4y ago

What you are seeing is a change in culture. X11 was very much a "everything is a work-in-progress" culture. Experiments were fine, clients and servers could support whatever they wanted, etc, etc. Wayland is an "opinionated" culture. Everything the core devs don't like is not allowed. Everything HAS to fit into the "every frame is perfect" mantra. Which is ridiculous over-engineering and disallows a large number of perfectly acceptable (to end users) use-cases.

teawrecks 4y ago
It's not worth driving away the vast majority of potential end users to cater to a small number of hackers through, even if the hackers were there first. When it comes to wide appeal, linux suffers from paradox of choice on multiple levels. But there are a huge number of people who want the stability of windows/mac/etc without the violation of privacy, as long as they don't have to spend ANY time configuring their system to keep it working. To them, just like fixing their car, that's someone else' job/hobby that they don't have time for or get any enjoyment from. I don't see any reason why Linux can't offer that experience, but only if we have a windowing stack that is very opinionated about the user experience. Maybe it's time for an X12, but the Valves out there trying to make a competitive experience on linux for consumers will be dumping their money into Wayland.
Arnavion 4y ago
>Wayland is an "opinionated" culture. Everything the core devs don't like is not allowed. False. If your use case is so important nothing prevents you from making your own protocol and implementing client and compositor support for it. It's exactly the same as X. (Note for those unfamiliar: I'm not saying "make a replacement for Wayland". Wayland is a collection of protocols that define one or more objects and the formats of their requests / responses / events. Showing windows is part of the xdg-shell protocol, etc.)
- grandinj 4y ago
  yes, technically you can do that. But if you actually want to __use__ your extension/protocol with someone else, it needs to get accepted into various core libs and repositories. ....And then the gatekeepers step up and your problems start.

asoneth 4y ago

I think the Window Controls Overlay[1] approach that Microsoft is proposing for Progressive Web Apps on windows seems like an interesting compromise to solve some of the issues you raise. Specifically that the client code is allowed to customize _most_ of the headerbar, with the exception of an area reserved for the window controls (minimize, maximize, close, etc). It seems like this approach would still support alternate or tiling window managers as they could omit or provide custom window controls. [1] https://blogs.windows.com/msedgedev/2022/09/27/closing-pixel-gap-native-web-window-controls-overlay/ https://blogs.windows.com/msedgedev/2022/09/27/closing-pixel...

chrismorgan 4y ago
Very nice! I hadn’t heard of that. I’m amused at how exactly it matches my mullings of how I’d do it in a web tech stack (manifest field, env() variables, navigator property with events, CSS property to indicate draggable area), with only a couple of missing pieces: the ability to match the appearance of the native controls and native conventions (e.g. `background: env(titlebar-area-background); color: env(titlebar-area-color); text-align: env(titlebar-area-align)`, though for best results you’d still need a little more here and there). I’ve thought of trying to design something like this for Wayland server-side decorations or at least making a better replacement for libdecor, but it wouldn’t help me personally and it’s clear that GNOME isn’t having a bar of the entire approach, so I sadly just don’t think it’s worth the effort.

deleted 4y ago

[deleted]