It's on basically all the new ones except where it doesn't make sense, such as:
Gamescope (designed to keep a game fullscreen at all times)
Cage (for kiosk machines, basically gamescope but for interactive maps in shopping malls)
Weston (the reference wayland compositor which should have protocols that everything uses, I'm not sure how useful it would be to add screensaver support to the reference implementation then have it popping up on in-car-displays when you're trying to follow a map while driving)
Everyone who needs it has it already.
There will probably be an ext-session-lock-v2 and get pulled into the traditional DEs at some point, but probably after a whole bunch of getting everyone around the table and in agreement on some security questions: how do we prevent malicious software setting themselves as a screensaver for a screenjacking attack?, what happens when the screensaver crashes?, that kind of stuff...
Counterpoint: X11 wasn't designed with today's security needs in mind, and developers were building based on the assumptions that those security holes would remain. We don't actually want everything that X11 had, we only want the good bits.
Are you only using a HDMI cable and have you not tried a display port cable?
FYI: The "HDMI Forum" didn't want to allow open source implementations of HDMI 2.1. They wanted to charge people a fee for using it. This is why people use display port, it has no fee and it usually has newer feature support earlier.
I think some of the downvotes might be annoyance at not knowing what servo is.
Everyone in the web and rust communities would know that it is the original rust application that the rust language was made to create: a new web browser built with memory safety and safe parallel execution as first concerns.
Parts of it ended up in Firefox then servo died when Mozilla fired a whole swath of their own devs.
It was stuck in limbo for a few years but has seen a revival under Igalia who have a history of fixing bugs and supporting/adding features to the existing browsers which the big players don't have the resources or the will to work on.
I do think every project needs a non-marketing-speak description of what it does on every major page that a user might visit (e.g. Homepage, project readme, releases/downloads page), but I wouldn't really call version 0.0.1 a proper release.
They basically said they didn't know about the issues with hyprland, they recently looked into them and to them in looks like hyprland has changed enough to be supported.
But, they were silent on the DHH. That part is the serious concern.
Hyprland is the project associated with Transphobia. To put it delicately, the original developer was so cringe to the point that others didn't want to work on the project.
DHH is the developer who is associated with White Supremacy, as he started making overtly white suprematist comments on social media.
In one case he points out that someone is making commits that have messed up a file's indentation, and to stop doing that because it's messing things up (they were).
In the other case he points out that rust's default format rules are wrong (in the context of version control readability, they are) and asks someone to fix them.
I'm more interested in what the Oil shell has been doing, it has a higher potential roof while keeping backwards compatibility rather than the current standard of affairs 10ish year development cycle of a new shell with slight improvements.
Switching shells can be a massive pain in the ass, so if we're making a change, it has to be worth it.
Oil looks like it could be worth it and then some.
I think it's mostly former apple users who like gnome (gnome 3 era anyway) the most, since to them MacOS looks awkward and slow.
Those users are shown too much in one go kde, lock up and scare themselves away from it.
KDE really needs to change how they introduce new users to it if they want to gain new users. The troubles this user had in KDE will actually help them do that in a small way, but they need more footage of first time users explaining what they are trying to do to help them see what's actually confusing of not obvious your first time around.
It's also too early to worry about DOM apis over wasm instead of js.
The whole problem with the DOM is that it has too many methods which can't be phased out without losing backwards compatibility.
A new DOM wasm api would be better off starting with a reduced API of only the good data and operations.
The problem is that the DOM is still improving (even today), it's not stabilized so we don't have that reduced set to draw from, and if you were to mark a line in the sand and say this is our reduced set, it would already not be what developers want within a year or two.
New DOM stuff is coming out all the time, even right now we two features coming out that can completely change the way that developers could want to build applications:
being able to move dom nodes without having to destroy and recreate them. This makes it possible so you can keep the state inside that dom node unaffected, such as a video playing without having to unload and reload a video. Now imagine if that state can be kept over the threshold of a multi-page view transition.
the improved attr() api which can move a lot of an app's complexity from the imperative side to the declarative side. Imagine a single css file that allows html content creators to dictate their own grid layouts, without needing to calculate every possible grid layout at build time.
And just in the near future things are moving to allow html modules which could be used with new web component apis to prevent the need for frameworks in large applications.
Also language features can inform API design. Promises were added to JS after a bunch of DOM APIs were already written, and now promises can be abortable. Wouldn't we want the new reduced API set to also be built upon abortable promises? Yes we would. But if we wait a bit longer, we could also take advantage of newer language features being worked on in JS like structs and deeply immutable data structures.
TL;DR: It's still too early to work on a DOM api for wasm. It's better to wait for the DOM to stabalize first.
Nah, he'd likely fall to recidivism with the other nazis in jail.
He should be forced to do some sort of aboriginal related charity in a position where he can only help them and not harm them for the rest of his life.
Good.
Don't you want AI slop to be easier to spot to the general public?