Most of that stuff was made available to universities and colleges as institutions, but not to individual students. Once you graduate, you have no effective (or legal) access to it anymore ...
> I'd take balkanization over the "we force-migrate everyone to the hot new thing where nothing works".
The UI framework for macOS has not changed in any substantial design-update-requiring ways since OS X was first released. They did add stuff (animations as a core concept, most notably).
The UI framework for Windows has changed even less, though it's more of a mess because there are several different ones, with an unclear relationship to each other. win32 won't hurt though, and it hasn't changed in any significant ways since dinosaurs roamed the silicon savannahs.
The UI framework for Linux ... oh wait, there isn't one.
> Windows is the only one that does this properly. Windows handles high pixel density on a per-application, per-display basis.
This is not our [0] experience. macOS handles things on a per-section-of-window, per-application, per-display basis. You can split a window across two monitors at two different DPIs, and it will display perfectly. This does not happen on Windows, or we have not found the right way to make it work thus far.
> macOS handles things on a per-section-of-window, per-application, per-display basis.
No, it does not. If you have two displays with different physical pixel densities, and especially if they are sufficiently different that Apple will consider one 'Retina' and 'not Retina' (this is usually the case if, for instance, you have your MacBook's display—which probably is 'Retina'—beneath a 2560 × 1440, 336 × 597 mm monitor, which is 'not Retina'), then the part of the window on the non-Retina display will be raster-scaled to account for the difference. This is how KDE Plasma on Wayland handles it, too.
In my opinion, any raster-scaling of vector/text UI is a deal-breaker.
I think there’s one group of people who consider preserving the physical dimensions important that like the macOS approach. For me, if a window is across multiple displays then it’s already broken up and I’m not too bothered about that. What I care about is getting application UI to a reasonable size without blurring. MacOS doesn’t do that.
Actually, the default in MacOS is that the window is only on one monitor, and its the monitor where the cursor was when you last moved the window, so you might have a window appearing invisible because you dragged it near the corner and some sliver ended on another monitor.
Look at this complicated tinkering MacOS makes you do for something as simple as spanning windows across monitors! https://www.arzopa.com/blogs/guide/how-to-make-a-window-span... (OK this last part is slightly facetious but Linux gets dinged for having to go into menus because the writer wants something to work the way it does in on other operating systems the whole time)
As an end user hand assembling desktop services on non-Systemd distros (Artix, Devuan, Gentoo, Guix) over the years, and thus had no concern about APIs, Pipewire just works and PulseAudio gave endless trouble.
As another user on Gentoo, pipewire is a never ending pain in the ass full of "magic" behavior and weird bugs. I mostly skipped pulse though so it may be simple in comparison to that.
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).
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.
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).
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:
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.
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.
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.
> By raising awareness of the situation, it has now become more slanted towards "peace in Palestine."
"the situation" changed from "more than a thousand Israelis murdered by Hamas" to the total destruction of Gaza, the death of tens of thousands and worse.
It's not exactly surprising that there was a shift in where public support is directed.
Do you understand how much more food we produce on roughly the same amount of land (globally) than we did 60 years ago? Claiming that we don't know how to be efficient at scale is absurd.
Now, it is true that these production levels are very dependent on a bunch of practices that are likely not sustainable, and that's a serious and pressing issue. But the problem is not efficiency.
Further, as others have noted here (and so have I), it is animal-based food production that uses so much of the water that we use, and that's a choice we've made (particularly in the USA). We could make different choices (and some of us have tried to).
None of it is sustainable without diverting Colorado River water. Human habitation alone might be below what you can currently get out of the river, but who knows what climate change will do to that.
I don't believe that this is true. Colorado diversions might be currently used for residential purposes, but only because so much other water is used by agriculture. I'm fairly certain (though not completely certain) that AZ, NM in particular could support their residential populations with no Colorado diversions at all.
Most of that stuff was made available to universities and colleges as institutions, but not to individual students. Once you graduate, you have no effective (or legal) access to it anymore ...
reply