leopold

I see. Will avoid, then. I don't like lucid dreaming, always wake up right away. Whenever I notice I'm dreaming it becomes hard not to notice that I'm in my bed and that I can feel my covers and by that point it's all over, so whenever I notice I'm dreaming I just cut the crap and open my eyes for a couple of seconds to wake myself up and then close them again so I can get back to proper sleep.

Is this really useful? Like, is this something people ever need to do? I don't do lucid dreams very often, but the rare times a dream has lead me to the thought of "hold on, am I dreaming?" were basically immediately answered by just, uh, vibes, I guess? Like, it's always just been instantly obvious that I'm dreaming the moment I'd start questioning it, no tests necessary. At worst I might have to try to remember what I did the day before and what I was supposed to be doing that day and see if that is at all compatible with the scenario I'm dreaming about, which it usually isn't.

Do you... not know how multi-licensing works? You can use the project's code under the terms of whichever license you prefer, you don't use all three at once. Simply putting the AGPLv3 does remove unfair restrictions, because it means you don't have to use either of the proprietary licenses the project was previously only available under.

I don't follow. ElasticSearch was only available under proprietary source-available licenses. Now, it's also available under the AGPL, which is open source, meaning ElasticSearch is now open source software. What part of this is deceptive or contradictory?

Calligra's support for OOXML files is truly garbage and shouldn't be used. Only use it with OpenDocument files.

Whoa, I was convinced Karbon wasn't going to see any further Calligra releases. Seemed to have zero maintainers last I checked, thought it'd go the way of Braindump and Author.

Huh? That's the best thing about Calligra by far. Why waste valuable vertical real estate on toolbars and ribbons when you can shove a sidebar in all of that empty wasted margin space? Plus, the whole thing is customizable. It doesn't have to be a sidebar if you don't like sidebars.

Regular Qt themes are compiled C++ programs that use the QStyle API to alter the look of Qt applications. They can do just about anything, but obviously require code to create. Being compiled programs also means they can't be portably distributed. They have to be recompiled for every different Qt version and architecture.

Kvantum is just one of those themes, and it uses its code to load and display much simpler SVG-based themes. Kvantum themes are actually much less complex than regular Qt themes, which is the whole point, since that makes them significantly simpler to create and much more portable, which is why they're so popular. The vast majority of Qt themes nowadays are made for Kvantum. Before Kvantum, it was mostly the less powerful QtCurve. Regular themes can do a lot of things Kvantum themes can't, but Kvantum is usually good enough.

Putting aside the fact that you're engaging in extremely blatant goalpost moving, WebKit is open source and is being used by open source browsers like GNOME Web.

servo is a lot further along because they're not bothering with javascript and are just using spidermonkey. see WPT: https://staging.wpt.fyi/results/?product=servo&product=ladybird

This is excellent news. I was always annoyed at the fact that Dolphin had to use its own thumbnailer API. Now apps can bundle one thumbnailer for their file formats that works with all file managers, which is great.

One thing that I always thought would be really interesting to see would be a Wine thumbnailer that would generate thumbnails using Windows thumbnails for Linux file managers. So for example installing Sketchup on Wine would give you skp thumbnails, since Sketchup is bundled with a Windows Explorer thumbnailer for those files. I know Wine already supports thumbnailer shell extensions in its built-in file manager, so it would just need to be able speak with Linux file managers.

Now I just hope to see something similar happen with service menus. Every file manager has its own unique format, but it's IMO the biggest obstacle to interoperability remaining with Linux file managers.