leopold @ leopold @lemmy.kde.social

Posts

46

Comments

329

Joined

2 yr. ago

No third party icon theme that I'm aware of makes of use of accent colors.

FDO stands for FreeDesktop.Org, the committee responsible for various desktop Linux standards including icon themes. So FDO icons just refers to your system icon theme, which LibreOffice doesn't use.

LibreOffice uses its own widget toolkit. It works similarly to wxWidgets, basically just maps to whatever toolkit is native on the current platform. It uses Win32 on Windows, Cocoa on macOS, Qt on KDE, GTK on GNOME and a few others.

That said, their current approach to dark themes is pretty bad. It can very easily conflict with the dark theme from the host toolkit and cause issues if misconfigured, which has caused a lot of people to think it just doesn't work. It does work, but it can be confusing as hell to configure correctly.

For instance, LibreOffice has a setting you can use to change the application colors. It barely works and you should never touch it. Just let it get the colors from your toolkit.

There's also the fact that LibreOffice doesn't use FDO icons and has its own icon setting which doesn't automatically follow dark/light theme. If you're using a dark theme, you have to manually switch the icon set to one that isn't impossible to see on a dark background.

Oh and if you want your documents to use a dark palette that's also a separate setting. Like I said, confusing.

Okular has JavaScript support. I think some things don't work, but it's worth a try.

Also, Adobe Reader had a native Linux version, so I wonder why the Snap is using Wine.

It used to be open source, but large parts of it have been relicensed under their proprietary source-available shared source license. The reason why it isn't entirely proprietary is that it's based on Firefox, which is entirely licensed under the MPL. The weak copyleft of the MPL states that all parts lifted from Firefox must remain open source, but the new parts can be proprietary.

Source-available licenses are a type of proprietary license where the code is made public for people to look at, but you're not actually allowed to use it. Users can still contribute upstream, so they're usually parasitic licenses aimed at getting free labour out of the userbase without actually giving back any code to the commons, all while keeping up the illusion of being open source. It sucks.

The job of the window manager is to manage windows and very little else. Font rendering is done by the widget toolkit, usually via freetype/harfbuzz.

Source? PipeWire was designed to use those APIs. This is the first time I hear about it causing any particular issues or overhead.

Dunno what you mean. JuK was ported to Qt6 last February alongside the rest of KDE. It's on Flathub and most distro repositories.

I set up mine same as I did on desktop. Copied my custom filters over and enabled all of the default ones. Works well enough.

Because it's not actually a good idea.

You create text that is basically impossible to search. Like, for instance, do a Ctrl+F on this page and search for "Bold". You'll see the example from OP doesn't get picked up, because it's not a B, it's a 𝗕. And it's not an o, it's an 𝗼. And so on. Or how about this? Go on Google and copy-paste this word from OP: "s̵t̵r̵o̵k̵e̵". Now, stroke isn't a particularly unusual word, but this thread is just about the only result Google returns. Because it's not stroke. It's s̵t̵r̵o̵k̵e̵.

It's also bad for accessibility. A lot of the time screen readers just won't know what to do with your bold or italic Unicode text.

And of course this only works for characters for which Unicode actually has these variants. Not a problem with the Latin alphabet, but what about Arabic? Cyrillic? Chinese? Devanagari? Hangul? Not gonna work.

These characters are from the Mathematical Alphanumeric Symbols code block. They're stylized Greek and Latin letters meant chiefly for use in mathematical contexts. The Unicode standard explicitly advises against using them to fake markup for the reasons outlined above and more. A simple markup language is just about always going to be preferable to faking it with Unicode.

Huh? How did you narrow it down to just GIMP? Are you excluding all non-GUI software or something? GUI has never been a big focus for GNU (which I assume is what you're referring to when you say FSF), though they do have a couple of projects like GIMP and GNUCash. Most notably as far as GUI is concerned, they instigated the GNOME project, though they later split off. But yeah, they still maintain extremely important tools, especially for developers and UNIX systems, such as glibc, coreutils, gcc, emacs, gdb, make, bash, grub, octave, guix, etc.

Source? Last I checked, the Steam Deck was very much in the minority even when narrowed down to just desktop Linux.

Yeah. xwayland isn't gonna die ever probably, so there's no rush.

like most apps on Linux, kde connect was never exclusive to any desktop. you don't need gsconnect.

At the moment, we have Blink (Chrome), Gecko (Firefox), Webkit (Safari), Servo, Ladybird and Goanna (Pale Moon).

At best, another Pale Moon is what would happen. They've been maintaining their own hard fork of Gecko by themselves since 2016. They clearly have people capable of maintaining a browser engine, though perhaps not quite enough of them. If Firefox were to die, perhaps joining up with Goanna would be the smart move.

There are significantly fewer Firefox-based browsers than there are Chromium-based ones, unfortunately. Out of the ones we do have:

Floorp has much like Vivaldi gone the proprietary source-available route, so you couldn't pay me to use it.

Pale Moon is easily the most involved of the Firefox forks, being a fork of a much older version of Firefox, but I wouldn't generally recommend it for security reasons. It does have its uses, though. Waterfox Classic is in a somewhat similar boat. Security-wise Pale Moon is definitely the better of the two because it uses its own fork of Gecko which is maintained about as well as you could reasonably expect given the manpower available to the project. Waterfox Classic meanwhile has kinda just been left to rot since most development is going to regular Waterfox nowadays, so it's not maintained nearly as well as Pale Moon and it's just been collecting CVEs. But for those same reasons if all you want is the ability to use legacy XUL extensions, then Waterfox Classic is gonna have better compatibility since it hasn't been modified nearly as heavily as Pale Moon.

LibreWolf is probably the most popular Firefox fork nowadays, but it isn't much more than a Firefox equivalent to Ungoogled Chromium. Waterfox goes a little further, but not by much. Both can be good choices, but personally I haven't had much reason to switch away from upstream Firefox. LibreWolf is tempting, but I can already disable pretty much all of the Firefox BS from about:config, so I don't see the point. It's pretty much just better defaults.

It is significantly less powerful when compared to LibreOffice, lacking support for many features. It offers less applications than LibreOffice. It is significantly less customizable than LibreOffice. It's built on bloated web tech. It lacks RTL support.

I am not paranoid about OnlyOffice's origin. I also do not think it is the best office suite on Linux by a mile.

The Steam Deck works well if you have a particularly twisted definition of "working well". SteamOS is certainly among the worst Linux distros I've used. It is certainly significantly worse than the average desktop-oriented distro. Sure, Valve has done good work with Proton, but basically every other piece of their stack is broken in some way.

Just a couple of days ago I had an issue where after the battery died and I plugged my Steam Deck into the charger, it simply failed to turn on. The fans would start spinning and that's it. Nothing else worked. I could not get into the BIOS menu. I could not get into the recovery menu. The solution? Unplug the Deck, let the battery die from spinning fans and plug it back in, hoping that time it'll turn on. Spinning fans take a long time to drain the battery, so this took me a couple of hours even though I'd only been plugged in for about ten minutes. I am not the first to deal with this issue. You can see posts online about it more than a year old. Those posts are how I was even able to figure out the solution.

I will never understand why SteamOS gets any kind of praise. This kind of issue is unacceptable. Any non-tech-savvy user will assume their device got bricked. I've seen several people mention they did RMA over this. And despite being a critical failure known for over a year, it hasn't been fixed.

If you're not a techy, SteamOS is garbage. It is ridiculously unpolished and keeps breaking in ways that can be difficult to fix. Every update (especially the client updates) has a 50/50 chance of breaking something, even on the stable update channel. You have to switch to desktop mode just to use a web browser. In fact, you have the switch to desktop mode for a lot of things, because gaming mode doesn't let you do things like adding non-Steam games, install Flatpak applications or use a file manager. But desktop mode is entirely unsuited for gamepad controls and the on-screen keyboard feels particularly sluggish (though it can also get sluggish in gaming mode, just not as often).

If you're a techy, SteamOS is also garbage. It is still ridiculously unpolished and the immutability is implemented in such a way that completely neuters the whole OS as anything you change gets wiped on every update (you can't layer). There are hacks to do most things from gaming mode. You can run Firefox with some kind of weird setup where you run it inside a nested KWin session, because Gamescope is completely incapable of handling multiple windows, which would normally break all of the context menus and the hamburger menu in Firefox. Similar deal with Dolphin for file management. You can even run the entire Plasma desktop nested inside Gamescope, albeit with some caveats. Still need to switch to Desktop Mode to add non-Steam games tho, since you can't run the desktop Steam Client from Nested Desktop. Things break occasionally, but it's manageable. Figuring out all of these workarounds is quite time consuming though. This would not be the case if SteamOS was actually a good distro.

Would need a decent port of JDK to RISC-V.