Comment by PaulDavisThe1st

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.

Reply View 2 replies

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

Reply View | 1 reply
- 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.
  
  Reply View | 0 replies

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.

Reply View 1 reply

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.

Reply View | 0 replies

dTal 5 days ago

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

Reply View 6 replies

PaulDavisThe1st 5 days ago

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

Reply View | 5 replies
- 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.
  
  Reply View | 1 reply
  
  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.
  
  Reply View | 0 replies
- eptcyka 5 days ago
  
  Systemd runs each userspace desktop application in it's own control group.
  
  Reply View | 2 replies
  
  jcgl 4 days 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.
  
  Reply View | 0 replies
  
  gf000 5 days 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.
  
  Reply View | 0 replies