Amikke @Amikke@qoto.org

Javascript is an excellent language to present language design problems, because
1. it's widely known
and
2. if something is possible to fuck up, there's a good chance js fucked it up.

@icedquinn @SuperDicq smart. I wonder if there's already a universal enough utility that would only have to have the QR generation added.

@icedquinn @SuperDicq oh I guess with the code you would have the benefits of both a fancy screenshot and computer-readable text.

@icedquinn @SuperDicq I don't really see a use for the QR code that isn't fulfilled by just copying the stuff to clipboard or taking a screenshot, but I guess it would be cool.

Also TIL that the KDE clipboard utility has a "generate QR code" option. Looks like there's no option to copy that to clipboard though lol, and even if there was it's ofc not as straightforward as having it be generated by the info tool directly.

@icedquinn @SuperDicq basically the system info tool that DEs often have by default, but with a QR code generator?

@OpenComputeDesign @Linux_in_a_Bit the latter usually don't actually pass. Their attempts to pass them are pretty damn annoying though, not gonna lie.

@jgillich @galdor especially the newer version where a lot of the bizarre gotchas were cut out. Not that many parsers support it lol

But besides that I often use YAML and recently had to quote "no" in the list of nordic countries. Funny stupid gotcha but easy to remember, beats quoting everything including identifiers in JSON.

@progo something like that xD

@progo I know, but for us in all of the other countries that use gregorian calendar it is 9/11 so we might as well post related memes.

@bersl2 Sure. But with the *nix focus on modularity instead of a giant overarching server, the thing we'd end up with would be wayland with a mustache and a fake nose. Cutting out everything except the protocol between the "server" that displays windows and "client" windows is the correct approach, leaving the server implementation and everything else modular. Restricting the ability for one program to snoop on another requiring building up other APIs (as protocol extensions or otherwise) for that is also correct imo.

This doesn't mean that we can't have a unified server module using common APIs for things traditionally handled by X and its extensions either, a lot of wayland compositors are built on wlroots and alike, which is functionally the equivalent of leaving everything except the WM and compositing to the common server, like in X. The only thing we lose is time required to adapt to this new standard and build up the ecosystem of protocol extensions and tools we've grown used to.

@icedquinn seems about right, no support means you can't use a controller at all and having sensible bindings is full support, so it makes sense that badly emulating a mouse would count as partial support. On the worse end, but still.

happy 9/11

#meme

It's honestly hard to believe the events of 2020 in the US actually happened. It's like a fever dream.

@IceWolf @foone yeah, let's all continue to use an eldritch abomination of a server and protocol to run all WMs, using more extensions than years since it went into maintenance mode so that it can at least pretend to function like a modern compositor, just because some DEs haven't yet fully agreed on protocols outside its scope.

Why stop there, let's force everyone to write programs to run under some shitty pre-defined runtime from the '80s because heavens forbid some may have different APIs and certainly won't agree on them ever.

@IceWolf @foone the year is 2030, people are still whining that Wayland is non-functional by design because some aspect of X11 that isn't even in the scope of the protocol doesn't work like in the old days. Meanwhile the rest of the population uses Wayland-based WMs.

@blake @whynothugo from what I've seen they forked Synapse away from the Matrix foundation's version to do that, this has nothing to do with the protocol itself.

@heatdeath is that recent jobs list written in Javascript perchance?