This is a somewhat hacky solution, but I’ve set up a thing in the past, where I would share a URL to my desktop via KDE Connect. And then on my desktop, I configured the default browser to be a script that I wrote.
This script would check, if the URL is a YouTube URL, and if so then open it via MPV (with yt-dlp also installed on the system).
If not, then just open it in Firefox as normal.

I have heard before that you can just add it to uBlock Origin, yeah.

Yeah, to some degree I get it. The guy does need help with some things and can’t perform certain physical tasks. And it is an entirely different thing to be tolerant to that vs. being married to it.

But the guy is kind-hearted, educated and sporty. He’s missing an arm, but others might be missing a brain or a heart, which I feel are much more detrimental for a partnership.
Unfortunately, though, dating someone with a visible impairment really gets the gossip going, and people are scared of that, so I guess, it’s better to date a dumb ass instead.

Having said all that, the guy is married by now and has a healthy son, so all is good in the end.

Built upon Mono and Gtk#

Oof, I tell you. Oof.

I doubt many devs will want to subject themselves to a Microsoft stack, so I wouldn’t put too much hope into a fork. Probably rather worth seeing if any of the current music players have a similar UX…

Yeah, I did not expect them to do that title justice, because how in the hell could anyone try 200 music players, but how did they get down to 7 and somehow skip some of the most popular players…? Did all of those somehow look broken on their setup? 🫠

I enjoy this comment. I don’t even know, if I’d rank NixOS as S-tier in general, but because I can handle it, yeah, don’t really have a reason to bother with other distros…

I mean, NixOS has lots of weird “defaults” in that sense, too. 🙃

A colleague has a badass metal arm and I can confirm that it’s a great conversation starter.

On the flipside, though, I can only imagine that it wasn’t easy to find a partner…

Yeah, fair enough. I was thinking in terms of the more general-purpose text formats. I have heard good things about QML, too…

Eh, I don’t think it’s the be-all and end-all of describing user interfaces, but it deals well with the deep nesting that UIs generally have, and the attributes allow throwing in metadata for certain elements, which is also something you frequently need in UIs.

At the very least, JSON, YAML, INI and TOML would be a lot worse.

Personally, the zero-setup filesystem snapshotting was a big argument for it. I do not want to use an OS anymore, which does not have snapshotting or an equivalent.

Thankfully, this is becoming more commonplace, but for years, openSUSE was the only player in that game.

I can’t imagine the country matters.

Do you just not have the “User Interface…” menu entry?

Hmm, that’s weird. Are you on a semi-recent version of LibreOffice? I believe, it got shipped with version 6.0.

And just to be sure, you are checking here, right?:

Well, HTTP + HTML+JS+CSS. The “World Wide Web”, if you will.

You can switch to the “Tabbed” interface for something more similar MS Office: https://books.libreoffice.org/en/WG252/WG2521-UserInterfaceVariants.html#toc6

Okay, dude, glad to have talked.

It’s pretty much just a hook into infodumping about medieval cities…

Link for those wanting to subscribe from other instances: [email protected]

Having to make a decision isn’t my primary issue here (even though it can also be problematic, when you need to serialize domain-specific data for which you’re no expert). My issue is rather in that you have to write this decision down, so that it can be used for deserializing again. This just makes XML serialization code significantly more complex than JSON serialization code. Both in terms of the code becoming harder to understand, but also just lines of code needed.
I’ve somewhat come to expect less than a handful lines of code for serializing an object from memory into a file. If you do that with XML, it will just slap everything into child nodes, which may be fine, but might also not be.

Ah, well, as far as XML is concerned, yeah, these are very different things, but that’s where the problem stems from. In your programming language, you don’t have two variants. You just have (person (name "Alice") (age 30)). But then, because XML makes a difference between metadata and data, you have to decide whether “name” and “age” are one or the other.

And the point I wanted to make, which perhaps didn’t come across as well, is that you have to write down that decision somewhere, so that when you deserialize in the future, you know whether to read these fields from attributes or from child nodes.
And that just makes your XML serialization code so much more complex than it is for JSON, generally speaking. As in, I can slap down JSON serialization in 2 lines of code and it generally does what I expect, in Rust in this case.

Granted, Rust kind of lends itself to being serialized as JSON, but well, I’m just not aware of languages that lend themselves to being serialized as XML. The language with the best XML support that I’m aware of, is Scala, where you can actually get XML literals into the language (these days with a library, but it used to be built-in until Scala 3, I believe): https://javadoc.io/doc/org.scala-lang.modules/scala-xml_2.13/latest/scala/xml/index.html
But even in Scala, you don’t use a case class for XML, which is what you normally use for data records in the language, but rather you would take the values out of your case class and stick them into such an XML literal. Or I guess, you would use e.g. the Jackson XML serializer from Java. And yeah, the attribute vs. child node divide is the main reason why this intermediate step is necessary. Meanwhile, JSON has comparatively little logic built into the language/libraries and it’s still a lot easier to write out: https://docs.scala-lang.org/toolkit/json-serialize.html