4 ms·

Because Wayland only does essential low-level stuff such as display and graphics it forced people to start coming up with a common Linux desktop (programming) i

by yason 9mo ago

Because Wayland only does essential low-level stuff such as display and graphics it forced people to start coming up with a common Linux desktop (programming) interface out of nowhere to basically glue everything together and make programs at least interoperate. Such an effort to rethink Linux desktop alone could've been a major project on its own but as having something was necessitated by Wayland all of it has become hurried and lacking control. Anything reminiscent of a bigger and more comprehensive project is in initial stages at best. If Wayland has been coming on for about ten years now I'll give it another ten years until we have some kind of established, consistent desktop API for Linux again. X11 did offer some very basic features for a desktop environment so that programs using different toolkits could work together, and enough hooks you could implement stuff in window managers etc. Yet there was nothing like the more complete interfaces of the desktops of other operating systems that tied everything together in a central, consistent way. So, Linux desktop interface was certainly in need for a rewrite but the way it's happening is just disheartening.

PaulDavisThe1st 9mo ago
Nobody has a user-space stick big enough to force things in the Linux world. When Apple dropped the old audio APIs of classic macOS and introduced CoreAudio, they pissed off a lot of developers, but those developers had no choice. In the GUI realm, they only deprecated HIKit for a decade or two before removing it (if they've even done that), but they made it very clear that CoreFoo was the API you should be using and that was that. In Linux-land, nobody has that authority. Nobody can come up with an equivalent to Core* for Linux and enforce its use. Consequently, you're going to continue to see the Qt/GTK/* splits, where the only commonality is at the lowest level of the window system (though, to Qt's credit, optionally also the event loop).
- mikkupikku 9mo ago
  GNOME has enough weight to at least force most projects to accommodate them. But unfortunately this has mostly been for the worst, as GNOME is usually the odd one out with most matters of taste and design.
  - jcgl 9mo ago
    Maybe to some degree that's true. But let's take an example: GNOME is the only (afaik) desktop that requires client-side decorations. They've been like that for years, but nobody else is following them on that. Yes, the toolkits and a number of toolkit-less apps have added support for them. But it's not like they were actually able to employ their gravity to change the world over to CSD (thank goodness).
    - account42 9mo ago
      I don't think GP claimed that everyone copied everything about Gnome, just that every toolkit/program has to implement Gnomes way of doing things even if they continue to support others so you have that as a common (but often bad) interface. CSD is a good example of that - implementations of it have reached libraries like SDL that would rather not care about the desktop user interface at all but because of Gnome they have to.
- dTal 9mo ago
  systemd comes close, and can be viewed as an attempt to create such a stick...
  - PaulDavisThe1st 9mo ago
    Sorry, but systemd has absolutely nothing, or even less than nothing to do with user-space GUI desktop applications.
    - eptcyka 9mo ago
      Systemd runs each userspace desktop application in it's own control group.
      - gf000 9mo ago
        No it doesn't. It could, but as far as I know this is not used at all. There are user services, but that's a separate concept.
      - jcgl 9mo ago
        Not exactly. Desktop environments (or whatever the program is that launches the application) decides to use systemd to run each application in its own cgroup. Systemd is certainly relevant to the Linux desktop as a whole, especially regarding logind. But there's no specific relation to GUI desktop applications that I'm aware of at least.
    - dTal 9mo ago
      Ah, if only! GNOME and even to an extent KDE both depend on systemd components, to the point that systemd-free distros are compelled to fork it if they want a GUI: https://wiki.gentoo.org/wiki/Elogind https://wiki.gentoo.org/wiki/Elogind Only yesterday I was wondering how it is that my brightness keys work in my desktop environment, when /sys/class/backlight/intel_backlight/brightness is only writeable by root. The (somewhat horrifying) answer is that applications can send a request to logind over DBUS, which checks the request against opaque and arbitrarily byzantine Polkit rules, and then writes to the sysfs file on the application's behalf, which it can do because it runs as root. It's unclear quite what this achieves that simply making the file writeable by the "video" group does not, but hey at least systemd gets to be involved. Incidentally, the correct command to change the brightness as a normal user from the command line is as follows: busctl --timeout=1 call org.freedesktop.login1 /org/freedesktop/login1/session/self org.freedesktop.login1.Session SetBrightness ssu "backlight" "intel_backlight" <brightness> So simple, so easy to remember, so superior to "echo <brightness> > /sys/class/backlight/intel_backlight/brightness". Google it for a fun thread on why the --timeout=1 is neccessary (it won't work without it!) - although I suppose I should be thankful for that little foible, as without it the thread wouldn't exist and I would never have figured out the command in the first place.
- account42 9mo ago
  You say that like it's a bad thing. If you have have an actually good design then you can convince people with those advantages instead of forcing them with a stick. I think that's the main reason many of us use Linux actually - because we didn't like what the big stick corpos wanted to force on us.
  - PaulDavisThe1st 8mo ago
    It's not necessarily a bad thing. But both Qt and GTK are entirely as well designed as, say, Apple's Core* frameworks for GUI development, yet neither has become the singular GUI toolkit on Linux. One can view this as a benefit of Linux or as a disadvantage. Both are true.

by yason 9mo ago

PaulDavisThe1st 9mo ago

Nobody has a user-space stick big enough to force things in the Linux world. When Apple dropped the old audio APIs of classic macOS and introduced CoreAudio, they pissed off a lot of developers, but those developers had no choice. In the GUI realm, they only deprecated HIKit for a decade or two before removing it (if they've even done that), but they made it very clear that CoreFoo was the API you should be using and that was that. In Linux-land, nobody has that authority. Nobody can come up with an equivalent to Core* for Linux and enforce its use. Consequently, you're going to continue to see the Qt/GTK/* splits, where the only commonality is at the lowest level of the window system (though, to Qt's credit, optionally also the event loop).

mikkupikku 9mo ago
GNOME has enough weight to at least force most projects to accommodate them. But unfortunately this has mostly been for the worst, as GNOME is usually the odd one out with most matters of taste and design.
- jcgl 9mo ago
  Maybe to some degree that's true. But let's take an example: GNOME is the only (afaik) desktop that requires client-side decorations. They've been like that for years, but nobody else is following them on that. Yes, the toolkits and a number of toolkit-less apps have added support for them. But it's not like they were actually able to employ their gravity to change the world over to CSD (thank goodness).
  - account42 9mo ago
    I don't think GP claimed that everyone copied everything about Gnome, just that every toolkit/program has to implement Gnomes way of doing things even if they continue to support others so you have that as a common (but often bad) interface. CSD is a good example of that - implementations of it have reached libraries like SDL that would rather not care about the desktop user interface at all but because of Gnome they have to.
dTal 9mo ago
systemd comes close, and can be viewed as an attempt to create such a stick...
- PaulDavisThe1st 9mo ago
  Sorry, but systemd has absolutely nothing, or even less than nothing to do with user-space GUI desktop applications.
  - eptcyka 9mo ago
    Systemd runs each userspace desktop application in it's own control group.
    - gf000 9mo ago
      No it doesn't. It could, but as far as I know this is not used at all. There are user services, but that's a separate concept.
    - jcgl 9mo ago
      Not exactly. Desktop environments (or whatever the program is that launches the application) decides to use systemd to run each application in its own cgroup. Systemd is certainly relevant to the Linux desktop as a whole, especially regarding logind. But there's no specific relation to GUI desktop applications that I'm aware of at least.
  - dTal 9mo ago
    Ah, if only! GNOME and even to an extent KDE both depend on systemd components, to the point that systemd-free distros are compelled to fork it if they want a GUI: https://wiki.gentoo.org/wiki/Elogind https://wiki.gentoo.org/wiki/Elogind Only yesterday I was wondering how it is that my brightness keys work in my desktop environment, when /sys/class/backlight/intel_backlight/brightness is only writeable by root. The (somewhat horrifying) answer is that applications can send a request to logind over DBUS, which checks the request against opaque and arbitrarily byzantine Polkit rules, and then writes to the sysfs file on the application's behalf, which it can do because it runs as root. It's unclear quite what this achieves that simply making the file writeable by the "video" group does not, but hey at least systemd gets to be involved. Incidentally, the correct command to change the brightness as a normal user from the command line is as follows: busctl --timeout=1 call org.freedesktop.login1 /org/freedesktop/login1/session/self org.freedesktop.login1.Session SetBrightness ssu "backlight" "intel_backlight" <brightness> So simple, so easy to remember, so superior to "echo <brightness> > /sys/class/backlight/intel_backlight/brightness". Google it for a fun thread on why the --timeout=1 is neccessary (it won't work without it!) - although I suppose I should be thankful for that little foible, as without it the thread wouldn't exist and I would never have figured out the command in the first place.
account42 9mo ago
You say that like it's a bad thing. If you have have an actually good design then you can convince people with those advantages instead of forcing them with a stick. I think that's the main reason many of us use Linux actually - because we didn't like what the big stick corpos wanted to force on us.
- PaulDavisThe1st 8mo ago
  It's not necessarily a bad thing. But both Qt and GTK are entirely as well designed as, say, Apple's Core* frameworks for GUI development, yet neither has become the singular GUI toolkit on Linux. One can view this as a benefit of Linux or as a disadvantage. Both are true.