Comment by yason

Comment by yason 5 days ago

13 replies

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 5 days 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 5 days 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 5 days 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 4 days 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.

  • account42 4 days 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 3 days 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.

  • dTal 5 days ago

    systemd comes close, and can be viewed as an attempt to create such a stick...

    • PaulDavisThe1st 5 days ago

      Sorry, but systemd has absolutely nothing, or even less than nothing to do with user-space GUI desktop applications.

      • dTal 4 days 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

        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.
        • PaulDavisThe1st 4 days ago

          As noted by others below, this has nothing to do with GUI desktop applications.

          Sure, systemd is involved in running the system on which those applications run, but the discussion was about some sort of equivalent to the unified GUI stack offered by macOS (the Core* frameworks) which are used by essentially every GUI application on that platform. Linux doesn't have that, and there's nobody in a position to force that on developers. systemd has nothing to do with this.

      • eptcyka 5 days ago

        Systemd runs each userspace desktop application in it's own control group.