I never thought I’d discover such a stupid design decision in KDE. I didn’t even learn about it on Planet KDE, but on KDE’s Facebook public group, which I joined for lack of a better idea.
If you’re using KDE, you must know what a Global Theme is. The problem with the way this is implemented in KDE Plasma is that one can get such themes from third-party creators. For your convenience, you don’t need to install such extra themes as packages offered by your distro; instead, you’ll get them from the so-called “official KDE store“–in fact, just like Xfce Look and Gnome Look, a section of Pling.com, a horrendous pile of turd that should never have existed. It’s messy, it looks like shit and, as many KDE users should have noticed by now, it often fails (I suspect the API fails, as the themes are not directly retrieved from the website).
The bad news
On March 20, I ran over the following FB post, which I reproduce below, so you don’t have to visit FB:
WARNING: Global themes and widgets created by 3rd party developers for Plasma can and will run arbitrary code. You are encouraged to exercise extreme caution when using these products.
A user has had a bad experience installing a global theme on Plasma and lost personal data.
Global themes do not only change the look of Plasma, but also the behavior. To do this they run code, and this code can be faulty, as in the case mentioned above. The same goes for widgets and plasmoids.
We are calling on the community to help us locate and quarantine defective software by using the “Report” buttons available on each item in the KDE Store.
Meanwhile, KDE is taking measures to properly warn users before each download and we are also putting in place ways of auditing and curating what is uploaded to the KDE store.
Nevertheless, this will take time and resources. We recommend all users to be careful when installing and running software not provided directly by KDE or your distros.
And remember to report any faulty products you find!
I just installed this Global Theme, innocently (Global Themes -> Add New…): … It DELETES all your USER mounted drives data. It executes rm -rf on your behalf, deletes all personal data immediately. No questions asked.
I’d appreciate it if anyone could escalate this, I find it totally mind blowing that installing skins allow script execution so easily. I cancelled this when it asked for my root password, but it was too late for my personal data. All drives mounted under my user were gone, down to 0 bytes, games, configurations, browser data, home folder, all gone.
It is 2024, we are using KDE on our work systems. I can understand the themes breaking styles and even the system, but this deserves way more than Morty’s “Oh, jeez”.
I understand this might be an isolated incident, but come on. For how long will themes be an afterthought? I like the default theme just fine, but the whole promise of Plasma being customizable is smoke and mirrors — themes are hit-and-miss, and execute whatever script they want during installation. No moderation. Wild wild West.
But it is nice you warn users that they should REVIEW the installation script. End-user. Not all of us are on Arch btw, I just want a stable system. Am I just being a snowflake for disliking this?
I started using KDE because I was expecting more abstraction from configs and scripts, installing a theme should not require elevated privileges.
Is KDE a bad fit for me, should I go back to XFCE or i3? Yeah, I might need to mess around with dotfiles but at least when I do everything myself manually and cook up DE like a Michellin-stared chef every time I install a fresh system it actually works.
Sometimes I ask myself why KDE.org is doing such a broad range of activities when their core product has problems like this.
And a reply to it, mirroring what I said about the API failing only too often:
I always found it very strange how badly downloading and installing global themes in KDE works. There have been older instabilities in KDE, but many have been addressed recently. However, global themes is still largely a big mess, in my experience. Half of the time, for me, it doesn’t even work without an error message, or it works after 20 seconds without any notification. I would love to be able to have a stable system to easily test-drive many different themes that people have created, but at this point, I am afraid to try.
Also, I’ve always found it strange that the most endorsed themes seem to have been downloaded only a couple thousand times. Is that globally? I mean, that’s not a lot.
A global theme on the kde third party store had an issue where it executed a script that removed user’s data. It wasn’t intended as malicious, but a mistake in some shell parsing. It was promptly identified and removed, but not before doing some damage to that user.
This has started a lot of discourse around the concept of the store, security and upstream KDE. With the main question, how can a theme have access to do this?
To developers it’s not a surprise that third party plugins can do this sort of thing. It’s as intended. A global theme can ship custom lockscreens, custom applets, custom settings and all of these can run arbitrary bundled code. You can’t constrain this without limiting functionality. … … What can we do better?
In the short term we need to communicate clearly what security expectations Plasma users should have for extensions they download into their desktops. Applets, scripts and services, being programs, are easily recognised as potential risks. It’s harder to recognise that Plasma themes, wallpaper plugins and kwin scripts are not just passive artwork and data, but may potentially also include scripts that can have unintended or malicious consequences.
No, Sir. What you need to do at KDE is called seppuku.
GT500 – They shouldn’t be allowing themes to execute code of any kind. That’s a massive security risk.
Alan_Peery – KDE has a gaping security hole, and all theme functionally that can run code must be disabled. Vetting themes is not an adequate solution.
I fully agree.
A few more selected comments to this article, on Facebook:
Any situation where untrusted code is executed is game over. The fact that scripts are allowed in a theme is a very serious issue and points to the very poor judgement of these KDE developers in general.
Anywhere else, this would be called A SECURITY VULNERABILITY.
“The KDE Store currently allows anyone to upload new themes and various other plugins or add-ons without any checks for malicious behavior.” Wow.
Of course, plenty of retards are mentioning containerization. WTF, for a theme? For the painting of window decorations?!
Why the hell on earth are themes able to run scripts or any executable at all? Why this shitty architecture? A theme is supposed to be a collection of graphics elements and a set of rules .css like. Why don’t stop unnecessary complexity? GNU/Linux must come back to the Unix philosophy.
Pretty much what’s on my mind all the time: Plasma basically has everything you need out of the box, but the young ones are always gonna explore themes without waiting for a review or the ability to check with the community first. I may not be a parent, but I would really like the ability to lock this aspect of customization behind a password before lending it to a kid. It’s not exactly parental controls, but it would really save me the trip from my island to explain which repositories to trust.
To which I replied:
Sorry, but “Plasma basically has everything you need out of the box” sounds like GNOME’s claim that “nobody needs theming.” Try something better. How about “no execution of any code in 3rd-party themes,” eh?
Rhetorical comment on the original post: “But why are themes, global or not, able to run scripts or any executable at all? Why can’t they be something like a CSS? Who was the genius who designed this shitty architecture, and why didn’t anyone stop them?”
Meanwhile, I asked Le Chat Mistral, Gemini and ChatGPT-3.5: “Global themes and widgets for KDE Plasma can and will run arbitrary code. Why can’t such theme be something like CSS, without the need to run any script or other executable?”
Excerpts from the answers: “KDE Plasma themes and widgets can contain arbitrary code because they are designed to be highly customizable and functional. Unlike simple CSS stylesheets that only define the look and feel of a user interface, KDE Plasma themes and widgets can include complex logic and interact with the system and other applications. … While this flexibility allows for the creation of sophisticated and dynamic themes and widgets, it also introduces security risks. Malicious themes or widgets could potentially execute harmful code or steal sensitive data. … That being said, it is possible to create KDE Plasma themes that are purely visual and do not contain any executable code. These themes would be limited to changing the appearance of the user interface without adding any new functionality or behavior.”
“You’re right, there are security concerns with KDE Plasma themes that can run arbitrary code. Here’s a breakdown of the pros and cons: …”
“In summary, while CSS-like styling can provide extensive customization options for themes, allowing arbitrary code execution introduces significant security risks and complexities that may outweigh the benefits of additional flexibility.”
I then asked: “But does styling of GNOME, XFCE, LXDE, LXQt require code to be executed?”
From the answers: “The styling of GNOME, XFCE, LXDE, and LXQt does not typically require executable code to be run. These desktop environments use CSS-like stylesheets to define the appearance of the user interface, similar to how websites are styled using CSS.”
“No, styling on GNOME, XFCE, LXDE, and LXQt generally does not require code execution. These desktop environments (DEs) rely on themes that use formats like CSS or their own theme languages, similar to how websites use CSS for styling. This offers a more secure approach compared to KDE Plasma themes that can potentially run arbitrary code.”
“The styling mechanisms used in desktop environments like GNOME, XFCE, LXDE, and LXQt typically don’t involve executing arbitrary code. Instead, they rely on configuration files or declarative markup to define the appearance and behavior of various elements within the desktop environment.”
My final question: is KDE designed in a suicidal way? Doesn’t really anyone realize how stupid it is to allow code execution for theming? WTF.
He replied:
Maybe you need to explore more the zip content. For many of those, it comes with a sh file that allows you to install in a easy way.
I replied, too:
I don’t need to explore anything. What I need is to use a desktop environment THAT IS NOT VULNERABLE BY DESIGN!
I fail to understand
I really fail to understand what “advanced” customizations and what kind of “actions” really, really must be allowed to be performed by a KDE theme. I wasn’t aware that KDE Plasma was designed by retards, for retards.
Sure thing, when KDE Plasma 4 was released, it looked like shit, and it crashed all the time, much more than KDE3. Those fucking stupid plasmoids were driving me nuts! Those plasmoids were mimicking the Windows Desktop Gadgets, a stupid feature of Windows Vista and Windows 7, discontinued in Windows 8 and later versions due to security concerns!
KDE Plasma’s plasmoids are currently called widgets. Most of them are useless, dumb, or both. I don’t understand why would anyone want to use such retarded widgets! Oh, and they can be broken, too!
Try the Comic Strip widget. When customizing it, you get the same messy crap that you already know from the Theme Store. Add some comic strips, then enable them; most of them will not work! Yeah, the 3rd-party widgets and the 3rd-party themes are two major piles of turd that are “features” of KDE Plasma!
KDE Plasma 5, starting with 5.5 or 5.6, became really stable, so I started to trust it. But how could I have known how irresponsible its developers were? They are still stupid and careless. Oh, KDE’s security is an end user’s problem, not theirs. Really? So when Discover says that a 3rd-party theme has an update, should I fear that it will break everything? (I just deleted the 3rd-party themes.)
Why KDE, part I: why not GNOME
I could never use GNOME because Nautilus is the only file manager in the known Universe that lacks a Compact List view. I wish someone at Red Hat would realize how ridiculous this is and how this makes them look mentally retarded!
A Compact List view is available in:
Caja, the original Nautilus in GNOME2
Thunar
Dolphin
PCManFM
PCManFM-Qt
Nemo
Xfe
ROX-Filer
CDE’s file manager
Windows File Explorer since Windows 3.0 if not earlier
‘Nuff said. But I’ll keep repeating it across the intarwebs until I see a single GNOME developer say, “Gee, why the fuck did we remove this view? Because we felt more than two views will be too many for our intelligent users?”
When in front of a computer, no matter the OS, I use my file manager:
70% of the time in the Compact View
20% of the time in the Detailed View
10% of the time in the Icons View
If I was forced to live without a Compact View, I’d rather commit suicide. You are not a retarded if you, personally, don’t need to use a Compact View; but you are a retard if you decide that nobody else should need such a view!
Not everyone uses the Compact View (Compact List, whatever you call it) mode all the time. When dealing with images, the Icon mode comes in handy. When the details are important, well, the Detailed list is to be used. But when I deal with folders having hundreds or thousands of files, my productivity would decrease by orders of magnitude if I didn’t have a compact view!
Now, some file managers (Caja, do you hear me?) default to a Compact View in which all the columns are having the same width. This can be disabled, though. In Dolphin, you can even choose values other than “infinite width”:
Unfortunately, it’s impossible to set the width limit in characters. You can do it in Thunar, but not from the GUI: it’s part of the hidden settings (Alexander Schwinn should be a GNOME developer); look for misc-compact-view-max-chars.
OK, but how about using GNOME with a different file manager? Is it because GNOME got less user-friendly by not providing a GUI for most configuration settings, thus requiring gnome-tweaks?
No, it’s not just that. While they interpreted “less is more” in the most stupid way possible, there’s more to that. There are a couple of more horrendous design choices:
GNOME Shell, which makes GNOME look as if it were designed for a tablet. I don’t want to search for apps and get an array of huge icons as a result! I want a menu with submenus, just like all the other desktop environments do!
GNOME is also the inventor (in GTK3, hence it contaminated XFCE too!) of the Client-side decoration (CSD), with inconsistent results (typically, the CSD fuck-up is worse in XFCE than in GNOME). I understand that they tried to solve the problem of the diminishing vertical space in the 16:9 scren ratio era (the 5:4 ratio was much better, should you be old enough to remember the 1280×1024 screens; I’ve also lived the 4:3 age of 800×600 and 640×480). However, the title bar becomes too cramped, to the point that it can be difficult to identify an area that can still be used to drag the window.
The tray icons. Possibly because GNOME doesn’t use two panels anymore (oh, why is everyone taking inspiration from fucking Apple?!), the legacy panel at the bottom corner is long gone, and with apps trying to add back tray icons into the top bar, the result is a complete havoc. This GNOME Case Study would be hilarious if it weren’t sad.
Speaking of Apple: even macOS’s Finder has four views, whereas GNOME’s Files has two! (Nonetheless, the Columns view in Finder is not related to a Compact list view, unfortunately; instead, it implements the Miller columns, which I don’t find usable at all.)
Why KDE, part II: why neither MATE, nor XFCE
Oh, but I used XFCE for quite a long time! Most recently, with Manjaro and Fedora. Here’s how I initially thought that XFCE is the answer to the ultimate question of life, the Universe, and everything.
So far, I explained why GNOME was out of question. MATE, while being a continuation of GNOME2, thus very familiar to me from the past, is somewhat inadequate for this point in time. OK, but maybe it’s stable, so I could focus on the actual software, not on the desktop environment, right? Abandoned by Clem for his spicier project, MATE is managed by Martin Wimpress, and there is an official Ubuntu flavor featuring it, so it can’t be that bad, can it?
As it happens, no matter the DE, I always find myself in situations when I need to use both GTK and Qt apps. I use an app because it fulfills my needs, not because it’s “visually integrated” in any given DE. I’m not alone in this approach, and that’s why there are mechanisms to provide a (more or less) uniform look for Qt and GTK applications, i.e. to apply a similar theme to windows “foreign” to a given DE: in KDE (and in LXQt) one can select a theme for GTK2/GTK3 apps, whereas in GTK-based DEs, one can theme Qt apps. Now, that your DE of choice, under your preferred distro, already comes with all you need, or that you have to install something like Qt5crt, LXAppearance, qt5-style-plugins, Kvantum, etc., plus a matching theme, that’s another story. What matters is that it can be done. On major distros, I however expect that the default theme for a DE either provides a similar enough theme for the apps that are not using the same UI toolkit, or at least it doesn’t break them.
For Ubuntu MATE, the “official” MATE distro and the one with the most polished look (sorry, Mint, you’re ugly, and you only use LTS releases), here’s what any dark theme, including their Yaru-MATE dark does to Qt apps, more specifically to Dolphin:
Nobody in Ubuntu MATE fucking cares that their theme breaks Qt apps when the dark variant is used.
Exit MATE. What about LXDE or LXQt?
I liked LXDE at some point, mostly because I liked PCManFM: the little file manager that could 😉 But LXDE has been abandoned, and Lubuntu is now using LXQt.
There is always a schedule mismatch when it comes to either of Debian and Ubuntu. When a new LXQt is released, you can only get it soon enough in rolling-release distros. Lubuntu backports isn’t quick enough, and they first backport for LTS releases, where everything is older, forcing you to resort to Snaps and Flatpaks. But let’s suppose that’s not a show-stopper.
What is a show-stopper for me is that the current maintainer of PCManFM-Qt is an ass. I described the topic two and half years ago, and it has to do with PCManFM-Qt removing a feature present in PCManFM, namely the Ctrl+1 to Ctrl+4 keyboard shortcuts that change the folder view mode. The current maintainer has closed Issue #558: Adding shortcuts to View menu claiming that there’s no need for shortcuts, “because the view buttons are on the toolbar now.” This arrogant creature has decided that the users must use the mouse instead of the keyboard!
I’ll tell you later why I disregarded Cinnamon; for now, let’s declare XFCE a winner. And I’ve used it satisfactorily enough, especially with xfce4-panel-profiles (installed by default in Fedora’s XFCE spin), because otherwise configuring the panels is a PITA.
While using XFCE, I had a complaint at some point. It concerned a vulnerability in Thunar, which I discussed in my post from May 21, 2021. It was CVE-2021-32563. To make a long story short, an update to Thunar 4.16.8 was necessary to fix this issue; alternatively, backporting the fix were also simple enough.
The fix was made available even before the CVE was published on May 11, but what did Ubuntu do? They only pushed it to the development branch (the next Ubuntu release), leaving all the supported Xubuntu versions vulnerable!
Sean Davis, which is the Xubuntu Technical Lead, and an Xfce Core Developer, simply didn’t know about this vulnerability, and when notified by me on Twitter, he answered that… “Security bugs affecting any Ubuntu-related project need to be reported on Launchpad. Without a bug report (Twitter isn’t really sufficient), nobody is alerted to the need to do something. Security bugs are typically handled by the Security Team.” Back then, I still had a Twitter account, so I replied: “If this is all a “Xubuntu Technical Lead, Xfce Core Dev” can say, then WHO should know when a Thunar update also includes a security patch? The end user, e.g. me? The Pope? Again: XFCE CORE DEVELOPER, DAMMIT.” Then: “It’s still a mystery how package & distro maintainers function nowadays. As a simple user, I was subscribed to many mailing lists 15 years ago. I expect an XFCE fan/lover/pkg maintainer to do at least that. Are you using Thunar? Never bothered to learn about its updates? Really?”
He couldn’t care less. The Xubuntu Technical Lead, which happens to be an Xfce Core Developer! (Do words still have a meaning nowadays?) Add to that the fact that in Ubuntu there’s a misunderstanding of semantic versioning: in version 4.16.8, 4 = major version, 16 = minor version, 1 = patch version. Patch versions should not introduce new features, but just fix bugs, including vulnerabilities. When a new patch version of an XFCE component is released (and I’m not talking of the development versions, which in XFCE have odd minor versions, in this case 4.17), the Xubuntu maintainers should check whether it fixes “regular” bugs or also vulnerabilities! Or, more reasonable, it’s patch, just fucking rebuild the package! It might fix important bugs! But Xubuntu’s stable release updates process is completely broken! Mind you, this is about the Xubuntu-specific packages, which aren’t that many. Consider XFCE unmaintained in Ubuntu.
That was about Xubuntu, but XFCE can be used in Fedora, Manjaro, openSUSE, Mint, Debian, etc. Truth be said, this vulnerability was slow to get patched in point-release distros…
The funniest thing of all? The exact same vulnerability, while not being reported for other file managers, was present and and is still present, right now, in both PCManFM-Qt and PCManFM!
Here’s what that CVE said:
When called with a regular file as a command-line argument, it delegates to a different program (based on the file type) without user confirmation. This could be used to achieve code execution.
One might say that this CVE is bogus, and that this vulnerability isn’t that much of a vulnerability. I might agree with you, especially in a world where KDE Plasma allows 3rd-party global themes to execute arbitrary code, but… let’s not digress. Just call any of pcmanfm and pcmanfm-qt with the name of an existing image file, and they’ll open the default image viewer with that file as an argument, without asking you first. Convenient, but officially a bad thing.
But what made me drop XFCE was an(other) attitude. I previously mentioned that Thunar has a customizable maximum width for the Compact View, but it’s “hidden” (not in the GUI). And I mentioned the name of Alexander Schwinn, which is the current Thunar developer. There was “an incident” when this new customization was introduced in Thunar.
I thought it was a bug, but it really was a feature. The bug was somewhere in Manjaro, because this feature had been enabled unexpectedly. But the bad design was that there wasn’t any easy way to turn it off or to tweak it: if it isn’t in the GUI, how was I supposed to know there’s a web page somewhere telling people how to tweak it?!
XFCE and Thunar having a very slow and limited changes and improvements, I’d expect that, when a new feature is added, it’s added in a professional and responsible manner. So I replied to the developer’s reference to that page of “hidden settings” and “rather exotic settings”:
Thanks for the quick response!
This being said, I’m afraid it’s not “my problem”, but rather “a situation”. If I’m honest, this is the only way I can answer:
xfce4-settings-editor doesn’t have a misc-compact-view-max-chars property already existing under thunar, so how are people supposed to know about it? By googling?
I hate the concept of “hidden settings” since I learned of undocumented API and hidden settings in Win3.1 almost 3 decades ago. Such things should have no place in Xfce (maybe in GNOME, if they feel like). Sure, I don’t expect them to be listed in man thunar, but still.
IMO, using of either xfconf-query or xfce4-settings-editor are improper solutions for a default setting that has a major impact on the users. Should someone not google for “hidden settings”, they would think Thunar is broken (which, objectively, is true!), especially after having looked for a direct, GUI way (Edit, Preferences) of disabling this feature, as they learned from Caja and Nemo. This is not “exotic”!
While (thanks again!) this allows me to “fix my problem” for now, I am delusional enough to hope that you’ll understand the shock I had when noticing that a feature with such an impact on the users has been rushed in without much consideration. The Compact View is crucial to some people, and GNOME’s Files is the only FM lacking it (despite even the FM in Win3.1 having a compact list view!). Therefore, I’d have expected, as a basic change management analysis, for someone to have considered:
a. Should this feature be enabled or disabled by default? Why? Is it likely that most people would like it enabled? If so, then enabled. Is this “exotic”? If so, maybe it should be disabled by default!
b. Should the user be somehow warned about this new feature? (Not a common practice, but it should be.)
c. How visible should be the option to revert to the previous behavior? (I.e. to disable it.)
d. Since we’re at configuring it: should we have enable/disable (Caja, Nemo), “semantic” configuration (Long, etc., see Dolphin), or numeric configuration? (Not “hidden”.)
As a maintainer, you’re obviously free to consider this issue closed. After all, I only reported an oversight.
As a user, I will confess that this is the first time when I’m seriously considering moving to KDE. They’re bloated, but at least when they add something out of the blue, I should (hopefully!) be able to revert to the old behavior without looking for “hidden” settings.
His reply:
Congratulations, that is one of the most acid comments I ever received for thunar.
If I’m honest, this is the only way I can answer
You are wrong. You as well could have answered politely, in a constructive way.
Hidden setting are bad
I agree. Though I did not invent the concept. But it is what we currently have for rather exotic settings like this one, and there actually is effort to improve the situation, as I already mentioned. See here for more details: !218
This is not “exotic”
Fine, Caja and Nemo have a ‘fixed column size’ setting, and you want the same for thunar … though after your acid posting here, you may understand that I don’t feel like spending my time on it, doing work to please you. I would be fine with reviewing a MR though, if you are able to provide it.
This change was in the dev version of thunar for 8 months, which even already was shipped via xubuntu. And it was in the 4.18 pre-release versions for a month. Though nobody cared so far to report, so I indeed still think most users don’t care, and the setting is rather exotic.
to hope that you’ll understand the shock I had when noticing that a feature with such an impact on the users has been rushed in without much consideration. The Compact View is crucial to some people,
What a pathos. I hope these people did not die because of me.
Seriously, it’s only about the default value of the ellipsize length, where 50 is really sufficient for most of my files. I could understand all the fuzz if it would be, e.g. a crash on some major part. … Though like this, IMO it’s rather ridiculous to make such a drama out of it.
change management analysis
Haha, what ? … you know that Xfce is developed by few volunteers, don’t you?
As a user, I will confess that this is the first time when I’m seriously considering moving to KDE.
Please, don’t hesitate to go for it. Personally, I really don’t need users like you.
Which I did! For three reasons:
If you’re fucking adding an “exotic feature” (something that almost nobody asked for), expecially in software that’s rather conservatively updated and improved, either you do it properly, or you don’t do it at all! Because if it gets accidentally enabled, and I cannot get rid of it, then fuck you.
The attitude. He could have said, “Oh, but it shouldn’t have been activated by default,” and “sure thing, when I implement something on the job I’m paid for, I’m considering aspects such as those you mentioned, but here, really, there was no time, and I’m the only one who etc. etc.” Instead, he mocked me, and he literally said he didn’t need users like me. Well, fuck you very much.
To me, the graphical file manager is an extremely important component of an OS. Carelessly fiddling with it is unacceptable.
Why KDE, part III: KDE is not perfect, but Cinnamon is worse
To put it bluntly, stupidity isn’t limited to GNOME. More specifically, Cinnamon disappointed me. I’ll show you why KDE has a more ergonomic design than most other desktop environments, but I have to criticize it too.
An example of how Linux is wrong to mimic Windows 10 in copying the macOS Dock can be seen in the way most desktop environments (KDE, XFCE, Cinnamon) now default to an icon-only Task Manager bottom panel, instead of the traditional one in which the windows’ titles could be seen. How retarded must one be to prefer to only see an icon, and to have to move the mouse and click in order to know what the heck that window is displaying, when the traditional view can typically accommodate up to 8–10 window titles (yes, I disable grouping too: this way, I can see much more of what I’m doing without touching anything)? Why should I only see some freaking icons, when I can see real information? The bottom panel is mostly empty if the windows’ titles are not shown! The original design introduced by Windows 95 is the most ergonomic of all!
Here’s a default view in KDE, with low height, and 11 opened windows: what’s the purpose of the huge empty panel space? Why can’t I know more about the opened windows?
And how am I supposed to see which app is running? Oh, that tiny colored bar on the bottom? Should I order new glasses? (Docks are stupid, full stop.)
Instead, the alternative is to have all the information you need at a glance:
In the above image, not less than 10 window titles could be displayed with reasonable truncation. Another 10 window titles, in a more standard, higher panel:
OK, I understand that KDE might have tried to mimic the experience that Windows users have had since 2015, when this fuck-up called Cortana started screwing their taskbar; people who added lots of shortcuts (even Win7 had a Quick Launch bar!) might get something like this:
And, without doubt, Win11 looks even worse, and it completely fucks the taskbar:
Except that… this is not Windows, and it does not have Cortana, Bing, or Copilot! This is fucking Linux with KDE!
But, as I said, KDE isn’t perfect: it doesn’t have sane defaults in two regards, so the first thing I do in any KDE distro is this sequence of 2 steps:
Right-click on the taskbar, and choose a saner alternative to the (default) Icons-only Task Manager, namely the classic Task Manager.
Right-click on the start menu button, and choose a saner alternative to the (default) Aplication Launcher, namely the classic Application Menu.
Yes, there are plenty of retards in KDE’s design team too; and yet, KDE is the lesser evil.
Now, take a look at the maximum width for one window title in KDE:
Cinnamon, once you enable the window titles, does this:
Someone must be severely retarded, yet they design user interfaces! (Clement Lefebvre didn’t find anything wrong with this design, did he?)
This proof of poor design alone should make people run away from Cinnamon, yet they don’t! (Did I tell you that 98% of the world’s population is rigorously stupid? Ask any misanthrope.)
With the above panel sizes and scaling, KDE uses the default width for up to 5 windows, and starts filling the space (and thus starts shrinking the window titles) starting from 6 windows upwards:
This could still be improved, i.e. the default window title size should be user-defined, but it definitely could be worse. Take a look again at how ridiculous Cinnamon is! “Grouped windo…” as if it weren’t enough horizontal fucking space to write anything more!
Is Cinnamon really that bad? Yes, its design is stupid.
But let’s discover another poor design decision in Cinnamon.
Let’s compare XFCE, MATE and Cinnamon in terms of how to define keyboard shortcuts, to only compare the GTK-based environments.
In XFCE, everything is on one screen, easy to find:
Similarly, in MATE everything is on one screen, bar the need to scroll down:
In the above two desktop environments, one can see everything at a glance, and click to make a change. In Cinnamon though… one has to click, and click, and click, and only see limited info at once.
First, there are settings associated to the first-level menu (here, “Windows”):
Then, the submenu entries have their settings too (here, “Positioning”):
While several key bindings can be assigned to an action, one has to click on each individual action to see what are the currently assigned key bindings! This is more than ridiculous and makes Cinnamon the worst designed GTK-based DE! They might come with the excuse that their design allows you to easily configure multiple keyboard bindings for a same action, but at what price? (Besides, the only useful duplicate key bindings are CTRL+C vs CTRL+Insert and CTRL+V vs SHIFT+Insert.)
More signs of poor-taste design. Do we really need such ridiculous pop-ups?
Generally, the design in Cinnamon is wasting a lot of space. The window below cannot be made smaller, not even in width:
This is how everything is in Cinnamon: a sore for the space-conscious eye. And yet, Linux Mint is extremely popular! To add insult to injury, KDE is the only major desktop environment that is not supported in/by Linux Mint! Clem must be at war with Qt…
What Dolphin still lacks
Oh, wait! I forgot to tell you what it is that Dolphin lacks, whereas Windows Explorer has had it since Vista.
Take a look at the ID3 information for this MP3 file:
The “Disc Number” tag, while displayed in the details for a file’s info, cannot be added as a column in Dolphin:
In Windows Explorer, it’s called “Part of Set”:
Now, the only consolation is this: no file manager can display this field under Linux! So, whereas Dolphin lacks it, the other file managers lack many more fields!
In theory, it should be easy to add it in Dolphin, but I wouldn’t bother to file a bug report, for a very simple reason: it would be implemented in KDE 6, and I intend to keep using KDE 5 for some time.
Why KDE, part IV: Qt and KDE fix a bug in the Linux Kernel
Yes, you’ve read it correctly. Someone at Qt bothered to fix a Linux kernel bug that the geniuses who surround Linus Torvalds couldn’t fucking care less about.
It concerns the exFAT filesystem, which happens to be the most portable filesystem for use with the major operating systems. I also prefer it (over NTFS) for the external drives (HDD, SSD) I use for the multiple backups of personal documents, pictures, e-books, comic books, music and video files. I’m not one of those stupid paranoiacs who want to encrypt their backups. On the contrary, I want to be able to access my backups no matter the OS! This is why I never encrypt the partitions of my drives on laptops and desktops: I want to be able to recover them, not have them locked forever in the case of an unfortunate failure! (Why is everyone behaving as if they were all working for the CIA? What fucked shit are they having for brains?)
Before describing the actual bug, here’s something that many Windows users might have noticed, yet this bug report for Windows Explorer is wrong: Bug in renaming a file on exFAT:
There’s a bug in renaming files on exFAT filesystems.
When renaming a file only changing letters to capital letters, after submitting the new name it doesn’t actually change the filename at all. So this is a silent fail (and that’s really bad). Only when adding or removing letters, it successfully submits the new name.
So this rename won’t work:
flowers.mp4 -> Flowers.mp4
After hitting enter, it’ll instantly change back to its old name.
This rename won’t work either:
FLOWERS.mp4 -> Flowers.mp4
Again, after hitting enter, it’ll instantly change back to its old name.
I don’t understand why this is, because the F is a different character than f.
I told you that 98% of the world’s population is stupid. In the case of Windows Explorer, the bug isn’t that the rename fails; it’s that Explorer fails to update the view, believing that the case sensitivity doesn’t matter. To fix this, in Windows Explorer, one has to hit F5 after such a rename!
Now, a real failure to rename files on exFAT when only the case changes really occurs in some file managers, including Directory Opus:
I purchased and installed DO after the date of the latest stable version, June 22, 2020, so I assume that is what I am running. Renaming a file in a lister fails when the only changes in the file name are case changes of individual letters within the filename, i.e. the before and after file names are different but are case-insensitive the same. If you attempt to change the filename as described and then hit enter after making the changes, the filename reverts back to the old name. Workaround is to make the change but add an odd letter and hit enter, then change the name again removing the odd letter and pressing again to reach the desired filename. Minor but definitely annoying.
Once again, the claim that this also happens in Windows Explorer is preposterous. Why can’t people hit F5 or perform a refresh in whatever way they want?! Heck, this refresh works even in Win7!
exFAT is a case-insensitive file system. Some things can behave unexpectedly, e.g. directory renaming that changes only case of some characters:
$ mv FOO Foo mv: cannot move ’FOO’ to a subdirectory of itself, ’Foo/FOO’
This happens because mv finds that destination exists (for case-insensitive file systems FOO and Foo are the same thing) and adds source basename to the destination. The file system gets rename(“FOO”, “Foo/FOO”) syscall and returns an error.
That was listed as a bug. Whose bug?! Also, exFAT is NOT a case-insensitive file system! Technically, it’s case-retentive – it knows the difference between names that differ in case, but won’t let you create two files with names that differ only in case. This is by design: the idea is to allow mixed-case file names, without the cost of actually allowing several files that would be identical if case were neglected. Note that even NTFS, which allows such similar files to coexist, isn’t fully case-sensitive: in Windows, tell any software to open a given file by the wrong name in terms of case-sensitivity, and it will open it!
In practice, here’s what I discovered back in January 2022, when I tried to rename the file 02_Tintin_in_congo.pdf to 02_Tintin_in_Congo.pdf on an exFAT partition: that it would work under Windows (don’t forget to hit F5 after renaming!), but it would fail in most file managers in Linux!
🔴 Caja: FAIL!
🔴 Nautilus/Files: FAIL!
🔴 Nemo: FAIL!
🔴 Thunar: FAIL!
🔴 PCManFM: FAIL!
🔴 PCManFM-Qt: FAIL!
🟢 Dolphin: IT WORKED! We’ll get to that, and to why PCManFM-Qt, despite being Qt-based, failed lamentably, just like the GTK-based file managers. (Renaming also worked in QtFM, but I didn’t take a screenshot; I used the RPM from RPM Sphere, on Fedora.)
🟢 Here’s how KDE’s Dolphin takes care of such cases on FAT32 and exFAT. In file_unix.cpp:
void FileProtocol::rename(const QUrl &srcUrl, const QUrl &destUrl, KIO::JobFlags _flags)
{
...
bool dest_exists = (QT_LSTAT(_dest.data(), &buff_dest) != -1);
if (dest_exists) {
// Try QFile::rename(), this can help when renaming 'a' to 'A' on a case-insensitive
// filesystem, e.g. FAT32/VFAT.
if (src != dest && QString::compare(src, dest, Qt::CaseInsensitive) == 0) {
qCDebug(KIO_FILE) << "Dest already exists; detected special case of lower/uppercase renaming"
<< "in same dir on a case-insensitive filesystem, try with QFile::rename()"
<< "(which uses 2 rename calls)";
if (QFile::rename(src, dest)) {
finished();
return;
}
}
...
}
...
finished();
}
And here’s the magic performed by Qt5 and used by KDE. In qfile.cpp.html:
bool QFile::rename(const QString &newName)
{
Q_D(QFile);
...
// If the file exists and it is a case-changing rename ("foo" -> "Foo"),
// compare Ids to make sure it really is a different file.
// Note: this does not take file engines into account.
bool changingCase = false;
QByteArray targetId = QFileSystemEngine::id(QFileSystemEntry(newName));
if (!targetId.isNull()) {
QByteArray fileId = d->fileEngine ?
d->fileEngine->id() :
QFileSystemEngine::id(QFileSystemEntry(d->fileName));
changingCase = (fileId == targetId && d->fileName.compare(newName, Qt::CaseInsensitive) == 0);
if (!changingCase) {
d->setError(QFile::RenameError, tr("Destination file exists"));
return false;
}
#ifdef Q_OS_LINUX// rename() on Linux simply does nothing when renaming "foo" to "Foo" on a case-insensitive// FS, such as FAT32. Move the file away and rename in 2 steps to work around.
QTemporaryFileName tfn(d->fileName);
QFileSystemEntry src(d->fileName);
QSystemError error;
for (int attempt = 0; attempt < 16; ++attempt) {
QFileSystemEntry tmp(tfn.generateNext(), QFileSystemEntry::FromNativePath());
// rename to temporary name
if (!QFileSystemEngine::renameFile(src, tmp, error))
continue;
// rename to final name
if (QFileSystemEngine::renameFile(tmp, QFileSystemEntry(newName), error)) {
d->fileEngine->setFileName(newName);
d->fileName = newName;
return true;
}
// We need to restore the original file.
QSystemError error2;
if (QFileSystemEngine::renameFile(tmp, src, error2))
break; // report the original error, below
// report both errors
d->setError(QFile::RenameError,
tr("Error while renaming: %1").arg(error.toString())
+ QLatin1Char('\n')
+ tr("Unable to restore from %1: %2").
arg(QDir::toNativeSeparators(tmp.filePath()), error2.toString()));
return false;
}
d->setError(QFile::RenameError,
tr("Error while renaming: %1").arg(error.toString()));
return false;
#endif // Q_OS_LINUX
}
unsetError();
close();
...
return false;
}
This is proper software development, folks! 👏👏🏽👏🏿
This is a Linux bug. Qt5 only fixes this on Linux, because on Windows, the single-step renaming is possible. In Linux, this should have been fixed at the kernel level, not at the Qt and KDE level!
🔴 But why is the Qt-based PCManFM-Qt failing, then? Because it’s a crappy, sloppy, and negligent port from GTK to Qt that still uses GTK for file operations, that’s why! In utilities.cpp:
bool changeFileName(const Fm::FilePath& filePath, const QString& newName, QWidget* parent, bool showMessage) {
// NOTE: g_file_set_display_name() is used instead of g_file_move() because,
// otherwise, renaming will not be possible in places like google-drive:///.
Fm::GErrorPtr err;
GFilePtrgfile{g_file_set_display_name(filePath.gfile().get(),
newName.toLocal8Bit().constData(),
nullptr, /* make this cancellable later. */
&err)};
if(gfile == nullptr) {
if (showMessage){
QMessageBox::critical(parent ? parent->window() : nullptr, QObject::tr("Error"), err.message());
}
return false;
}
// reload the containing folder if it is in use but does not have a file monitor
auto folder = Fm::Folder::findByPath(filePath.parent());
if(folder && folder->isValid() && folder->isLoaded() && !folder->hasFileMonitor()) {
folder->reload();
}
return true;
}
bool renameFile(std::shared_ptr<const Fm::FileInfo> file, QWidget* parent) {
FilenameDialog dlg(parent ? parent->window() : nullptr);
dlg.setWindowTitle(QObject::tr("Rename File"));
dlg.setLabelText(QObject::tr("Please enter a new name:"));
// NOTE: "Edit name" seems the best way to handle non-UTF8 filename encoding.
auto old_name = QString::fromUtf8(g_file_info_get_edit_name(file->gFileInfo().get()));
if(old_name.isEmpty()) {
old_name = QString::fromStdString(file->name());
}
dlg.setTextValue(old_name);
if(file->isDir()) { // select filename extension for directories
dlg.setSelectExtension(true);
}
if(dlg.exec() != QDialog::Accepted) {
return false; // stop multiple renaming
}
QString new_name = dlg.textValue();
if(new_name == old_name) {
return true; // let multiple renaming continue
}
changeFileName(file->path(), new_name, parent);
return true;
}
In PCManFM-Qt, renameFile calls changeFileName, which invokes GLib’s g_file_set_display_name(), but it could have called g_file_move(), with the same results: if there is an underlying error, then there is an error, full stop.
static GFile *
g_local_file_set_display_name (GFile *file,
const char *display_name,
GCancellable *cancellable,
GError **error)
{
GLocalFile *local, *new_local;
GFile *new_file, *parent;
GStatBuf statbuf;
GVfsClass *class;
GVfs *vfs;
int errsv;
parent = g_file_get_parent (file);
if (parent == NULL)
{
g_set_error_literal (error, G_IO_ERROR, G_IO_ERROR_FAILED,
_("Can’t rename root directory"));
return NULL;
}
new_file = g_file_get_child_for_display_name (parent, display_name, error);
g_object_unref (parent);
if (new_file == NULL)
return NULL;
local = G_LOCAL_FILE (file);
new_local = G_LOCAL_FILE (new_file);
if (g_lstat (new_local->filename, &statbuf) == -1)
{
errsv = errno;
if (errsv != ENOENT)
{
g_set_io_error (error, _("Error renaming file %s: %s"), new_file, errsv);
return NULL;
}
}
else
{
g_set_error_literal (error, G_IO_ERROR, G_IO_ERROR_EXISTS,
_("Can’t rename file, filename already exists"));
return NULL;
}
if (g_rename (local->filename, new_local->filename) == -1)
{
errsv = errno;
if (errsv == EINVAL)
/* We can't get a rename file into itself error here,
* so this must be an invalid filename, on e.g. FAT
*/
g_set_error_literal (error, G_IO_ERROR, G_IO_ERROR_INVALID_FILENAME,
_("Invalid filename"));
else
g_set_io_error (error,
_("Error renaming file %s: %s"),
file, errsv);
g_object_unref (new_file);
return NULL;
}
vfs = g_vfs_get_default ();
class = G_VFS_GET_CLASS (vfs);
if (class->local_file_moved)
class->local_file_moved (vfs, local->filename, new_local->filename);
return new_file;
}
So what are they doing here? Some developer has considered the case when the file system being FAT32 or exFAT, such a renaming error might occur, and what they decided to do was… NOTHING! And this is why MATE, Nautilus/Files, Thunar, and Nemo just fail miserably! 😠😡👿👻
One more reason to prefer Dolphin and KDE!
Revenons à nos moutons
That was a long detour meant to say that I’ll keep using KDE, despite the irresponsible design choice of allowing third-party global themes to execute code, and the dumb overall decision of not disabling this “feature” (read: vulnerability) altogether.
I am not and will not use third-party themes, and neither should you. KDE global themes shouldn’t be freely downloadable, especially as they can run code; they should be available as packages provided by your distro.
I’m only using Plasma color schemes, such as Card, which are just sets of RGB values. You too should delete all unofficial global themes. If any such theme cannot be deleted from the GUI (systemsettings), look in these two places: ~/.local/share/plasma/desktoptheme/ and /usr/share/plasma/desktoptheme/.
I am not a true fan of any desktop environment, and I don’t choose a program based on the underlying UI framework (GTK or Qt). However:
I prefer a desktop environment with reasonably sane defaults, with a quick and easy way to adjust it to my needs, generally following the desktop metaphor introduced by Win95, and with good ergonomics (“human factors” if you’re an American). Currently, KDE is the best choice based on these requirements.
The file manager is of extreme importance to me, productivity-wise. Here too, KDE’s Dolphin tops everyone else.
I happen to prefer (read: need to use) some Qt-based programs, such as:
Featherpad: while not part of KDE, it’s a small gem, and my everyday editor of choice. Regex-based search and replace works just fine. (For MDI and code, there are many alternatives to Kate, such as Sublime Text, VS Code, VS Codium, PyCharm, etc.)
KRename: I cannot live without it. Again, Regex-based file renaming is a must.
Haruna Media Player: because I simply hate VLC. In Windows, I prefer MPC-HC, but there is no Linux version of it. MPlayer and SMPlayer are pathetic.
Audacious: for MP3 files. In recent times, it has defaulted to the Qt-based GUI.
All things considered, to learn about such a vulnerability by design was a shock to me, but I recovered.
☮️ Слава Україні! 🕊️ Stop the genocide in Gaza and the apartheid in the occupied West Bank!
The Fedora project is currently considering a change for future versions of the distribution which would switch the default Workstation edition’s desktop from GNOME to KDE Plasma. GNOME has always been the primary desktop for the Fedora distribution, but the change proposal outlines several areas where KDE’s Plasma desktop would offer a better experience. Some of the features the proposal highlights are Plasma’s system tray, Wayland support, and a reduced learning curve for new Linux users: “Plasma provides a more traditional user experience that could be viewed as being more approachable to everyday computing users, serving as a smoother “on-ramp” to using Linux-based operating systems. Alongside its wide breadth of personalization capabilities, it provides an out-of-the-box desktop experience that is more predictable than some of its counterparts. As an example, Plasma provides a system tray for applications supporting StatusNotifierItem (e.g. Flameshot, OBS Studio, VPN clients), which is not functionality supported by default in GNOME Shell and requires an extension which may break between releases.” The proposal is being discussed and whether it will be adopted has not been confirmed.
Unfortunately, despite the great arguments given by Joshua Strobl, and in spite of a few positive opinions, the discussion doesn’t go well.
● Most people believe that GNOME is “more intuitive”! For whom? For those coming from macOS? From those coming from iOS or Android?
● Too many people consider Wayland to be extremely important. Unlike you’re a brainwashed gamer, there’s nothing wrong with X11.
● “Fedora Workstation Gnome works out of the box.” So do the other spins!
● “My partner, and my a friend of mine, are both neurodivergent. They have both used KDE Plasma, and they have both used GNOME. They have both hated KDE for its complexity compared to GNOME, where they said “it just works” on GNOME. GNOME UI and app design makes their computers easier to use in comparison to Windows. My parents who are PC illiterate have a better time with GNOME because their skills from phones and tablets pass over. KDE Plasma does not provide this in my experience.” OK, so GNOME is for the mentally retarded. Duly noted.
● “KDE is just to “Windows”-ish for me… I don’t want to lay any icons on my desktop… this GUI had it his time in the 90ies and 2000…” Desktop icons are not mandatory under KDE, you nincompoop!
● Matthew Miller, the current Fedora Project Leader, cries in huge letters: “Wait, wait, hold on a minute please! … I’m not going to shut down this discussion topic (at least not immediately!), but I do ask: proposers, please withdraw the Change Proposal, or FESCo, please decline/defer…”
It’s gonna be rejected. 110%.
It’s worth noting that ABSOLUTELY NOBODY ever mentioned the severe limitations of the Nautilus aka Files file manager! The only major file manager that only has 2 views, and no Compact List View, and ABSOLUTELY NOBODY feels the need for such a compact view!
I’m more and more persuaded that GNOME fans must be mentally retarded!
This blog uses technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent will adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Not an April Fool! As reported by DistroWatch:
Unfortunately, despite the great arguments given by Joshua Strobl, and in spite of a few positive opinions, the discussion doesn’t go well.
● Most people believe that GNOME is “more intuitive”! For whom? For those coming from macOS? From those coming from iOS or Android?
● Too many people consider Wayland to be extremely important. Unlike you’re a brainwashed gamer, there’s nothing wrong with X11.
● “Fedora Workstation Gnome works out of the box.” So do the other spins!
● “My partner, and my a friend of mine, are both neurodivergent. They have both used KDE Plasma, and they have both used GNOME. They have both hated KDE for its complexity compared to GNOME, where they said “it just works” on GNOME. GNOME UI and app design makes their computers easier to use in comparison to Windows. My parents who are PC illiterate have a better time with GNOME because their skills from phones and tablets pass over. KDE Plasma does not provide this in my experience.” OK, so GNOME is for the mentally retarded. Duly noted.
● “KDE is just to “Windows”-ish for me… I don’t want to lay any icons on my desktop… this GUI had it his time in the 90ies and 2000…” Desktop icons are not mandatory under KDE, you nincompoop!
● Matthew Miller, the current Fedora Project Leader, cries in huge letters: “Wait, wait, hold on a minute please! … I’m not going to shut down this discussion topic (at least not immediately!), but I do ask: proposers, please withdraw the Change Proposal, or FESCo, please decline/defer…”
It’s gonna be rejected. 110%.
It’s worth noting that ABSOLUTELY NOBODY ever mentioned the severe limitations of the Nautilus aka Files file manager! The only major file manager that only has 2 views, and no Compact List View, and ABSOLUTELY NOBODY feels the need for such a compact view!
I’m more and more persuaded that GNOME fans must be mentally retarded!
Well, Matthew Miller has eventually closed the thread. Nothing will change in Fedora regarding KDE.