Because it’s literally advertising for LLM companies. Because certain news sites conclude from it that “AI did $thing” instead of “engineer did $thing, using whatever tools they found useful”. Because you can’t actually enforce it, which makes the tag completely useless.
Any of these reasons is good enough on its own.
plasmashell supports gifs and videos, and it runs on the GPU, not the CPU.
Plasma is started in nested mode, so it can’t control any physical screens.
If you start a session with the drm backend manually, it might work that way - if you do have those DisplayLink drivers working. The USB port does not support DisplayPort.
They were discussing the global shortcuts portal for about 10 years, with different portals and revisions, and they just couldn’t agree on
That’s just complete made up nonsense.
Some desktop environments used some draft versions, and everyone did it in a slightly different way, so that it wasn’t a real standard yet.
That’s not how anything works. An API getting further refinements and improvements - almost exclusively in documentation - doesn’t make it “not final” or “not a real standard”.
And many other window managers or desktop environments didn’t even attempt it
Some niche WMs not suppporting an API doesn’t matter to most app developers.
The global shortcuts portal is four years old.
That’s wrong. You can’t stream from the SteamOS game mode specifically, but streaming from a Linux desktop works.
Also, using C++ has vtable/exception overhead. No-go.
That’s just nonsense. The kernel and most other big C projects are full of structs with manual re-implementations of vtables.
If you don’t want exceptions (I don’t either), C++ doesn’t require you to use them. KDE software builds without them.
Mostly, a good library on C++ (Qt used to be one of those, but it’s started becoming annoying in the past few years) offers a lot of what Rust enforces at the language level.
I like C++, but let’s not pretend that’s actually true. Qt is completely full of really unsafe APIs, most of them quite old by now. It certainly doesn’t offer anywhere close to any safety Rust provides.
Even something as innocent as passing a pointer to Qt’s javascript engine can end up in use after free, and the signal+slot stuff goes wrong real fast once you do need multi threading.
(which is not to single out Qt specifically, the STL has plenty of really stupid and unsafe APIs as well)
xdotool should work the same in the Wayland session, assuming you give X11 apps the permission to emulate input. What about it isn’t working?
uinput is not the proper way, it’s emulating a hardware device.
The remote desktop portal is the proper way. Even xdotool works through that.
Plasma widgets are a gaping security hole.
Aka “thing that isn’t sandboxed, never has been sandboxed, and never has been claimed to be sandboxed, is in fact not sandboxed”. Just like any app from your distro repositories, or appimages, or games in Steam… Or even most Flatpaks by default for that matter.
Widgets being sandboxed would be cool and is a long term goal (which is way easier said than done!), but don’t present them not being sandboxed as some irresponsible thing someone does because they don’t care. Your expectations of security simply are simply completely misplaced.
What do you mean? Screen savers have been possible for many, many years…
VRR doesn’t require additional bandwidth.
Try Linux on a 4k HDR 120hz TV and see what happens.
It works fine, with chroma subsampling. At least I personally don’t ever notice it on the TV.
That’s not to say this getting fixed isn’t important, but it’s mostly relevant for monitors and maybe smaller TVs that you sit closer to.
Not the person you asked, but I do have the new controller, and it works as they described it.
How it works afaik is that SDL has a driver for it, even if the kernel doesn’t have a generic one yet. The controller also works in emulators without Steam running because of that.
Suspend works just fine with Fedora KDE on my AMD Framework 13. I don’t know about hibernation, since I use FDE and Linux still doesn’t support encrypted hibernation.
All the distros use fprintd, but that’s not related to Framework aside from the laptop using a sensor that fprintd supports.
Wayland as a protocol was designed around CSDs, protocols for SSDs came years later
That’s not an argument for anything. The core protocol isn’t useful on its own, you always need extensions that came later to even create a window. As another example, Wayland as a protocol was designed around shared memory buffers, protocols for hardware acceleration came later. Doesn’t mean you’re supposed to leave that out.
Modern apps tend to prefer CSDs anyway since it provides more flexibility, very common on MacOS and Windows
That too is not an argument for not implementing what a ton of apps need.
MacOS and Windows don’t do the same sort of CSD as Gnome FYI, it’s more of a hybrid approach, where parts of the decoration are rendered by the system and parts by the app.
It’s difficult to coordinate things between the client and compositor.
That too isn’t relevant, libdecor doesn’t coordinate shit either. And if you want to (which is being looked into), you can absolutely sync things with SSD too.
The actual and only reason Gnome doesn’t support SSD is that they think CSD is a “better architecture”.
The programming language has absolutely nothing to do with the size or maturity of a GUI library using it.