The absolute state of KDE software

Let's get this one out of the way first. This is probably something that will be on many readers' minds right now, given that it was just given as a reason for why e.g. OpenSuse doesn't ship KDE projects.

Simply put, there's no fixed cadence for KDE projects. KDE Gear comes out at a different time to the KDE system. So if you ship both, you have shall we say some head-scratching to do. Instead of having one "sure-thing" go-to solution, you have multiple compromises that offer different trade-offs.

The simplest one of those is to go with a rolling release. There are multiple successful projects that do things that way. Arch Linux would be on everyone's mind, but there's also OpenSuse Tumbleweed (this will be important), Gentoo, Debian, Void linux, just to name a few. For a rolling release, the staggering of major changes is a huge boon, as instead of having all of the edge cases popping up all at once during the major changeover, you get two relatively smaller blips on your radar. Of course, no matter what the Arch-bros would tell you, the fixed-schedule release distributions cannot just go rolling-release. This requires an inordinate amount of skill and architectural foresight to execute correctly, and unfortunately this kind of thing would be impossible to do in an environment where packages need to be patched before entering the distribution repositories.

So then we have the compromise solutions; on the one hand, we could wait until both gear and plasma have released. In that case, the release window gets pushed uncomfortably forward, but April - October release cadence worked well for Ubuntu, and Kubuntu, and KDE Neon don't seem to have much of an issue. The second option is to squeeze into the middle of the release of gear and plasma, having one outdated compared to the other. At this point one also has the option of adding in the newly changed pacakges into the fixed-release cadence. This might work out really well. In my experience with Fedora 16 with KDE, it was anything but. As I said, a rolling release requires quite a different set of skills and Red Hat didnd't seem to possess them at the time. Given how OpenSUSE (and SUSE in general) are linked to RHEL, I'd wager that the problems are similar, though mitigated by their experience working on Tumbleweed.

Then there's some options for which the release cadence is irrelevant: Debian holds back packages by a significant amount of time. As a consequence there's significantly fewer unknown unknowns, namely the interactions between the packages.

Now, all of these options are limiting. Most good architectures are. I can see some distributions giving KDE a hard pass, but I don't think that this explains the fact that of the mainline distributions almost none ship KDE by default and almost all ship Gnome.

No we need to dig deeper.

KDE packages are not inert. When they get installed, they can express in a myriad of ways. In fact, this is one of the main ways in which KDE is different from many other Desktop Environments; it allows an unbounded array of customisations.

So why is this relevant?

Many desktop operating systems, including Mac OS and Windows have dialed back their customisation options. In fact Gnome itself has undergone a similar transformation; Gnome 2 was a lot more customisable, and to an extent simpler system, where one could lock down dangerous components, and simultaneously ensure that an engineer trained on working with one version of the environment could work on another no matter how different the two machines.

Theoretically, this would mean that anything related to customisation has an evolutionary pressure. If your standard workstations run KDE, how can you ensure that your users don't utterly destroy the UI? How do you ensure that all your engineers know how to use this tool in all the possible forms that it can take? Well, it's usually simpler to limit the forms in which your UI can appear, to hide the problematic knobs to ensure that the users do not customise their workstation, and so that all workstations, save for colours and things which do not affect navigation and don't sacrifice on accessibility, are all exactly the same.

This means that there would be a convergence on a single Desktop that has reasonable defaults (Gnome), good accessibility (Gnome), discourages customisation (Gnome), has a reliable developer (Gnome), a reasonable test coverage (Gnome), and finally, a strong sense of loyalty to corporate vision (Gnome). You see, any form of self expression is yet another variable that makes the business calculus problematic. So any distribution that is aimed at providing an operating environment for a business, will itself try to limit the variability. With me so far.

While this theory would explain simply why Gnome has a strong advantage in the enterprise space, it does not mean, and probably should not mean, that it cannot be dethroned. On the contrary, Gnome has made a significant number of mistakes, that KDE has not yet capitalised on, but could.

Gnome has an unstable UI, so Gnome 3 and Gnome 40 series are almost completely different, negating the advantage of lack of customisation.

Gnome has an unstable extension API, so workstations cannot be uniformly modified. Their defaults are fixed, but anything beyond that is not guaranteed to be. At the same time, extensions cannot be all guaranteed to always work all the time.

Next Gnome doesn't have a robust understanding of "sane defaults". In fact, other than tiling Window Managers (which are ironically very similar to each other), Gnome is perhaps the maximally unfamiliar desktop environment for most users of primarily Microsoft Windows.

Gnome has shoddy code quality. And I don't mean in the subjective aesthetic sense of "I don't like the Gnome code base", I mean in the sense of having bugs, not implementing common APIs, implementing them too late and implementing them poorly. This problem can sometimes backfire in Gnome's favour, like for example, when instead of using xdg-desktop-portals the spyware zoom implemented screen capture via the Gnome screenshot D-Bus api. This gave Gnome a temporary advantage, in the sense that there was a time during which only Gnome's Wayland session had support from mainline proprietary meeting applications. This is also why some large Open Source projects tend to put Gnome support at the bottom of their list.

So what can KDE learn from this?

This is a program that I have no issues on a technical level with. It is perhaps the best code editor that doesn't use a turing-complete language for configuration.

It works out of the box. It uses a reliable syntax highlighting system. It interfaces with language servers out of the box, and handles them in the best possible way.

The only bad things I can say about Kate relate to the plugins. They are not the kinds of plugins I would expect from KDE software; there's no page on kde-look.org that contains a billion plugins, nor is there a way to get more than the ones that came with it.

❯ paru -Ss kate
extra/haskell-cheapskate 0.1.1.2-621 [357.12 KiB 2.02 MiB]
        Experimental markdown processor.
extra/kate 23.08.4-1 [9.41 MiB 30.25 MiB] [Installed] (kde-applications kde-utilities)
        Advanced text editor
extra/libkate 0.4.1-9 [115.50 KiB 331.43 KiB] [Installed]
        A karaoke and text codec for embedding in ogg
extra/libkate-docs 0.4.1-9 [153.52 KiB 1.86 MiB]
        A karaoke and text codec for embedding in ogg - developer documentation
extra/libtiger 0.3.4-7 [24.22 KiB 63.10 KiB]
        A rendering library for Kate streams using Pango and Cairo
extra/skate 0.2.2-1 [6.16 MiB 19.53 MiB]
        A personal key value store
extra/ttf-iosevkaterm-nerd 3.1.1-1 [59.17 MiB 731.54 MiB] (nerd-fonts)
        Patched font Iosevka Term from nerd fonts library
aur/ttf-cheapskate 2.0-20 [+12 ~0.00]
        TTF Fonts by Dustin Norlander
aur/kate-git 21.07.70_r17988.g3d0d58325-1 [+6 ~0.00] [Out-of-date: 2023-10-21] [Orphaned]
        Advanced Text Editor
aur/lib32-libkate 0.4.1-6 [+5 ~0.00]
        A karaoke and text codec for embedding in ogg (32-bit)
aur/kate-root 23.08.4-1 [+1 ~0.16]
        Advanced Text Editor from the KDE project, patched to be able to run as root.
aur/kate-wakatime-git 1.3.10.r1.g3c03b34-1 [+1 ~0.00]
        Kate plugin to interface with WakaTime
aur/katex 0.16.9-1 [+1 ~0.00]
        Fast math typesetting for the web
aur/libkate-python3-git 0.4.1-6 [+1 ~0.00]
        A karaoke and text codec for embedding in ogg. With fixes and port to Python 3 of before broken KateDJ.
aur/olliolli-hib 1414459118-1 [+1 ~0.00]
        2D skateboard plateformer
aur/python-sphinxcontrib-katex 0.9.9-1 [+1 ~0.00]
        A Sphinx extension for rendering math in HTML pages
aur/kate-indexview-plugin 0.9.1-1 [+0 ~0.00]
        A fork from Kate's SymbolViewer plugin with a couple of improvements
aur/katex-dist-bin 0.16.8-1 [+0 ~0.00]
        Fast math typesetting for the web
aur/libkate-git 0.4.1-6 [+0 ~0.00]
        A karaoke and text codec for embedding in ogg. Without broken KateDJ and Python2.
aur/mdbook-katex 0.5.9-1 [+0 ~0.00]
        A preprocessor for mdbook to render LaTeX equations in HTML
aur/mingw-w64-libkate 0.4.1-2 [+0 ~0.00]
        A karaoke and text codec for embedding in ogg (mingw-w64)
aur/otf-gt40 2021-1 [+0 ~0.00]
        A free recreation of the GT 40 Mono Font by Kate Willaert
aur/pandoc-static-katex-git latest-2 [+0 ~0.00] [Orphaned]
        A simple pandoc filter that uses KaTeX to render math equations at build time.
aur/qilin-bin 0.4.0.alpha-2 [+0 ~0.00] [Orphaned]
        Fully hackable text editor developed for exact sciences with built-in KaTeX and AsciiMath support
aur/skate-git 0.2.0.r9.g693df1f-1 [+0 ~0.00]
        A personal key value store
aur/skate-ipsum-bin 0.0.13-1 [+0 ~0.00]
        Skate Ipsum is a tool for generating random skateboarding related text.

Look, there isn't much here.

So there are two lessons here for the price of one:

The player is fine I guess.

In terms of sound quality I still prefer Audacious, even though from the UI perspective Elisa seems to have a tiny advantage. But I would not say under any circumstances that Elisa is a good player, given that it pulls in VLC, and cannot work without it, I wonder what exactly is it that Elisa is other than a skin around the VLC libraries (which, no offence to VideoLan, is probably why the sound quality is not-so-great).

Compare this to Lollypop. This player is, for lack of a better term, magnificent. It depends on gstreamer which in my humble opinion sounds slightly (but only slightly) better than VLC. But unlike Elisa it doesn't require me to pull in an entire graphical application to do the heavy lifting. Also, I wouldn't go so far as to say that it makes the music not hit. I'd go so far as to say that it sounds better than mpv in most cases.

But the difference is there, and it is noticeable; when I play a track in Elisa, yeah sure, I can appreciate the structure and relationship of the notes to each other. But I cannot, for example "feel" the music. Both players are incomparable to audacious in that respect, which is superior to both, even before you get into the weeds with all of the possible sound processing plugins that it ships with by default.

Secondly, the organisation of things into a single list with all albums visible at once, and being able to play them, is … an organisation choice. I would expect that Elisa does things differently for reasons of trying to facilitate a playlist-centric, rather than album-centric listening experience. But I'd argue that enforcing a paradigm is a very Gnome thing to do. I cannot turn Elisa into an album-centric player like I could with clementine or Amarok.

While I would be the first person to criticise Amarok (coming from FooBar2000 on Windows), I think that Elisa is a step backwards. At least with Amarok I had the option to choose the phonon backend, which would have let me use GStreamer. I don't have that same luxury with Elisa.

This is probably the only program in KDE that I outright hate.

One of the main reasons for this, is that it has many misguided decisions laid at the heart of its architecture. Pamac, for all its faults, was a package manager I was comfortable with. The Muon package manager, brief though its existence was in the Kubuntu flavours, was better. Hell, I would go down as to say that despite the complete ineptitude of apt, the only thing that made it palatable was synaptic-package-manager.

And this is a key point. The whole reason for the existence of software management front-ends, is that they allow one to do more precise operations with their package registries. The same I'm afraid is not true of Discover. Half the time, I don't know if it genuinely has no updates, or that it does, but those updates couldn't be displayed for a reason of which Discover is aware of, but does not show.

But let's assume that everything works, and the problems are related to the somewhat esoteric set up that I have. What is the design of the program?

From a purely marketing perspective, it does a terrible job. Everything is kinda cramped, there are cards which show (at best) a single icon. I assume that nobody is aware of the concept of screenshots, but that is far from the only problem.

There's no separation between GUI programs and system utilities. So I cannot go into discover and install git. I can, fortunately install something that accidentally pulls in git as a dependency, but this is not something that would ease a younger prospective programmer. Similarly, I cannot remove git. For some insane reason, even though I have plenty of pacakges with git in the name, the only thing that I can remove is a digital clock. Or rather I would be, if it wasn't installed with, I don't know, plasma-meta, which means that the naive dependency resolution method will try to uninstall everything for which this package is technically a dependency. And I get it, different pacakge managers do things differently. But I would like some more information other than "dependency resolution failed". I understand that this is probably due to the fact that you are trying to support too many package managers, but that only counts as a valid reason if you actually supported anything other than vanilla binary pacakge managers.

Discover doe not allow me to add a new pacakge repository. Thankfully on something like Arch Linux, you should realistically have no more than four, and avoid things like chaotic-aur like the flame, in favour of an AUR helper. At the same time, I am able to install Flatpaks and Snaps, and they are given first-party support, despite being glorified yum and apt for people who don't know how to statically link. One thing I would have appreciated is first-party support for AppImages, but there isn't any. nix and guix? No luck. So Discover, doesn't nearly have the coverage it needs to justify abstracting away valuable (I'd argue the most valuable) information a package manager can provide.

So maybe the UI is good for GUI programs. Unfortunately the no-form-no-function genie struck here again. Firstly, almost none of the pages communicate what a program actually does. Because there's no way of seeing a screenshot before clicking on the description. If the blurb doesn't entice you, you will not find out.

Secondly, there's no way of marking several applications for installation. You can only add them to a live queue. This is OK-ish, most modern package managers can cope with that. But it is something that a professional would like. The reason is, that sometimes you cannot remove one package, because it's a depedency for another package, but if you try to remove both, you would be able to mark them both and dependency resolution passes. This minor tweak to the UI would save the user from having to know ahead of time which package depends on which application (oh and Discover does show you libraries and applications, just not consistently).

I can't sort by modification or upload date, I can't group by repository availability, I can't sort by installed size. The only things I get in return for it being a graphical application is the ability to stare at the window, and realise how much space is being wasted drawing lines that don't help. And it's oftentimes faster for me to pull up a terminal and type in pacman -S kate than it is to do so inside of discover.

Plus, I don't know whose brilliant idea it was, KDE plasma widgets appear in Discover in addition to regular packages. But for some reason things like pip packages, cargo packages and many other useful packages don't.

What the FUCK ARE YOU TRYING TO MAKE DISCOVER DO?! Not only do I not get what its use case is meant to be (given that it asks the user to set up appstream, instead of doing it for them), I doubt that it has a use case that is not overshadowed by a distribution-specific graphical application that handles package management.

And we have good choices. On Arch alone, there's pamac and octopi that while having rough edges (something that can be fixed) also have a clear goal and cover both professional (i.e. tech-savvy) and newbie use cases. It has a similarly useless set of cards, but at least I can tell at a glance which of the packages can be installed and which can be removed. It also comes with the nice feature of supporting the AUR, and showing me just the packages; all of the packages at once. And pamac is an under-developed piece of shit.

I can at least mark several pacakges at once, which allowed me to uninstall edwood and acme. It gave me a clear error message for why I couldn't remove just acme and I could remove git, because at the very least it showed up in my search. If an application developed by people who forget to renew an SSL certificate does better than you in the first 15 minutes of systems administration, then you know that you've done something badly.

And if you want a positive example; take synaptic or octopi. Those programs are reliable, well-made if a bit ugly. They might not have form (Discover doesn't either), but at the very least they have function. And function they do! I have a list that I can sort and filter by whatever I like, I have the option to enqueue many operations, and it does what I need it to do, whenever I tell it to remove a specific package. It's just plain better.

I'm lumping all of the programs together, because my comments probably pertain to all of them at once.

Creating an office suite, especially on Linux, and especially in an environment wherein any difference from Micro$oft Office are heavily suppressed, is difficult. Plus, most of the time, even though Microsoft can afford millions in development costs, and probably doesn't need to, while simultaneously extracting huge profits, LibreOffice et al are all fundamentally working on a shoestring budget. They are not celebrated for their achievements, but shunned for losing in an unfair competition.

Sure one could make the argument that GNU Linux itself is fighting a similarly uphill battle, but at the same time, consider that the vast majority of people that use windows, have very good reasons to do so. They have very good reasons to continue using Windows and unlikely to switch unless there's a very good reason to switch. And with Microsoft Office, because it is meant as a medium of exchange, and one cannot individually decide not to use Microsoft Office and expect there to be no repercussions, there is a lot less good will.

So I would say that the office suite has potential but is miles behind anything even remotely comparable. Make no mistake, I would use a decent office suite over LaTeX any day of the week, especially if it had a well-defined domain-specific language that defined the document. Incidentally lyx is perhaps what I would have liked the industry to move towards… but that program has its own issues, and they need to be touched upon separately.

So what can I say? They do not reproduce documents reliably. This is a dealbreaker, and something that shouldn't but has still happened with the open XML-based formats. When MS office was moving away from a binary format, towards an extensible plaintext format (which is kinda dumb), the world was dominated by XML. Nowadays the world has moved on to JSON, and writing a document processor based on JSON is something even a mediocre JavaScript kiddie can do in a matter of hours. At the same time, LibreOffice and many of its brethren still rely on XML and at that, fail to reproduce the open document formats reliably. And that means that a document written in LibreOffice cannot be relied upon to be accurately represented in the respective KDE office application (which shall not be named). This is not acceptable and something that must be fixed eventually. At the time of writing, however, given the apathy towards office formats that are not Google Docs, it's unlikely to happen.

Calligra words (OK I lied), is a fine application that is basically useless. It's not fun to interact with and the kinds of people that keep Emacs and Vim alive, are not going to spend hours of their life fixing the problems inherent in an XML-based document format.

Spreadsheets? This is slightly different. Only slightly, because there seems to be consensus that the cell-based accounting system that is inherent in spreadsheets is not a great solution long-term. Do you know of many accounting firms that use Excel directly and if you did, would you trust them? More importantly, the data is often either shared in a format in which the spreadsheet is irrelevant (e.g. CSV) or in which accurate data reproduction with its limitations is paramount. Believe it or not, there are good reasons to believe that some of the NHS is still running on the original binary Excel format, and not the new-fangled XML-based one.

Calligra spreadsheets offer less for scientists (unless like me, they refused to use something like Python, until eventually succumbing to the dark side and enjoying the biscuits), it offers less for accountants than even the most basic home-baked system, and because Macros can be problematic, I don't exactly feel that I'm missing out on much by not using spreadsheets.

The one application that will not go away and that will likely remain useful for as long as we exist, is the presentation package. The issue is that everyone already knows how to use powerpoint, and presentations made with it or its numerous templates don't stand out, but rather blend in. And a lot of the time, despite its many drawbacks, the Mac OS presentation software produces vastly superior output.

Presentations are where there is ample opportunity to get creative, and to stand out. Support for shaders would have been nice. Standard representation formats, with standard animations is precisely what QML is good at. And more importantly, it would allow the presenter to create an ever-evolving template and visual style. Alas, while only some of it is possible with LibreOffice, the remedial capabilities of Calligra Stage are overshadowed at every step. The program is simply too simple to be useful.

And this is the best case scenario for Open Source office suites. Often one either presents a non-interactive PDF, or presents from their own device¹. In these cases, surely running Calligra Stage would give you an edge, or at least wouldn't put one at a significant disadvantage? Well, sadly…

And at this point, the bigger question is why hasn't KDE embraced the approach to standard document formats that have Open Source implementations and a wide usage. And indeed, why not embrace the fact that most of the time, if the person isn't already using Google Docs (as a fits all bucket for formatted text), or Microsoft Office (because they have to, because it's an institutional policy), they might be using something like LaTeX, or typst, or ConTeXt.

And indeed, there's kile which, if marketted correctly, could easily beat Microsoft Word in terms of its capabilities. It is not exactly WYSIWYG, and it isn't nearly as welcoming as MS Word, which is a great shame. With enough elbow grease, however, it can become something greater than the sum of its parts. The reason I still think that it needs elbow grease has to do with the fact that while I myself feel comfortable writing LaTeX, I don't think that many other people are. And on that note, the people that do write LaTeX for a living (scientists, for example) rely on Overleaf to serve as a facsimile of Google Docs.

Overleaf offers collaborative editing capabilities, and cloud storage with a pre-configured LaTeX distribution. Of these problems, Kile maybe solves the issue of installing LaTeX locally, which due to the way that LaTeX works is tens of Gigabytes of mostly useless junk that might be useful some day.

And in principle, Kile is a superfluous program, it doesn't need to exist, in any right world it'd be a plugin for Kate. It doesn't offer anything that a decent tiling window manager, Okular, Konsole and Kate couldn't do or do better. It doesn't even offer a rudimentary terribly WYSIWYG as Overleaf does.

And Overleaf is the bare minimum. I cannot fathom working on my research paper in Kile, given how much AucTex, RefTex, Git and CDLaTeX save me in terms of hassle. And if I really needed to do online collaborative editing with someone who was using a similar technology, I would use `crdt.el`. Your specialised program should not be overshadowed by a text editor maintained by a bunch of weirdos like me.

If we're completely honest, program like Lyx are a step in the right direction, but they languish in not having support and honestly not having enough to justify continued development. Too much coupling, too little freedom. Lyx could help, if it provided a library on which people could experiment with creating their own GUI. But that is kinda the problem. The reason Kile exists, is because the problem is naturally factored into pdflatex that handles compilation and konsole ensuring interaction. Some knowledge and some rendering for commonly used symbols. Okular to display the document and Kate to render the code and edit it efficiently. If Lyx were to factor the problem into re-usable components, it would survive. Sadly, it doesn't. It's a take-it-or-leave it program that uses some Qt libraries but doesn't show any interest in integrating with KDE.

Cantor is a different story. Most of today's science is done in a literate programming environment. Unlike org which provides a decent DSL for that, the most common format for exchanging such developments are based around something known as jupyter_notebook. Cantor provides an alternative that renders notebooks in a native GUI, with possibly better integration and more introspection. It is easier for one to debug (in the sense of knowing the internal state of the Python interpreter), the notebook via Cantor. However this program is hopelessly obtuse, most people wouldn't look twice at it.

LabPlot might be a useful program for some aspiring scientists, but when I needed to create a library for producing posterior plots, extending LabPlot didn't seem to be feasible. The KDE programs don't provide the back-end elbow grease and require quite a commitment from the only people that can benefit those projects. It's difficult to make an application that is using Qt to integrate with KDE, and much less so well. Not least of which, because of the technical debt that these projects only seem to accumulate.

So what can I say about Karbon². It is a decent application. It offers a way to edit SVGs that isn't hopelessly laggy (inkscape), but it doesn't exactly let me do things to the same extent to be extant in the graphic design world. Make no mistake a talented graphic designer would be able to squeeze out some use out of Karbon, but most talented graphic designers are too smart to squander their time on sub-par tools. It needs a lot more time in the oven, for it to be competitive with better tools. I would even go so far, as to say that it might benefit from being Audacitied-ed.

So where does that leave us, technical people that run Linux on the daily, not despite, but because of the learning curve, and the benefits that are being offered by customisation? Well, KDE software doesn't seem to add much, despite having great potential.

SVG editing ought to be a visual ordeal, but if I needed to fix some vector graphics (e.g. a plot) I would probably do so in Python first. Would I bother with Kile given the existence of Vim, Emacs, TextMate, VSchrap or Kate? Probably not, these editors are competent enough to accomplish the tasks well, without any support.

If I needed a GUI for Python, would I bother with Cantor? Maybe, but I have to make a conscious effort to do that.

Would I use LabPlot for a scientific plot? The issue is that as a technical person, I'm expected to be able to extend matplotlib to plot exotic plots based on data that needs to be processed. It's difficult to do that in LabPlot.

I would say that this program needs more love. Either someone should just copy over the features of QBittorrent, or at least make it extensible, so that I could if I needed to download media sequentially and with the first and last pieces first, currently I cannot.

Incidentally, if KTorrent had support for plugins it would have been an excellent platform, the fact that the program hasn't been updated in the sense of being majorly refactored, is a benefit, if what it means is that older plugins can still work, and work well.

This is a program that I have personally struggled with and will continue to struggle with for a very long time.

Why is this program challenging to use? It's too involved. Yeah, I know what an imap server is, and what an SMTP protocol is. Why do I need to configure them separately? Why does there need to be this silly situation of not being able to just send emails by choosing from a drop-down box of identities. Yeah, there are edge case mail servers for which this isn't true. Don't cater to the fucking edge case!

The program very routinely breaks, it suffers from problems when connecting to both a Microsoft Exchange email server³, gmail and for some reason the one place you'd think it'd shine, a plain old IMAP + SMTP server with no bells and whistles is also where it almost never delivers. I constantly have doubts about whether or not my email will come from the right address with the right signature. And I don't mean a Cyrilic or Armenian signature to an English-speaking recipient, I mean a GPG signature from an email account that I don't want to expose to the other people.

So why the fuck do I put up with this bullshit? I don't know, honestly, but it probably has to do with the way the UI is designed. Sure there are significant headaches associated to how KMail is configured. But when it works, it gives you a snazzy, threaded view with icons that indicate different things. Thunderbird is tied in terms of capability. KMail runs in the background, so I can technically not worry about having it running in the foreground.

I will mention that it is somewhat problematic to achieve the same results with my otherwise favourite tool – Emacs. You just can't beat a purpose-built application that leverages a native toolkit and was optimised for performance. In all fairness, simplification is the modus operandi with its successor, Merkuro, that I can't even run with a .desktop on an Arch Linux machine, because it doesn't seem to have the full confidence of the people that designed it. Worse yet, the backend of the system, is the problem. There is very little for me to expect a completely rewritten backend architecture, and despite major strides in the common-case configuration, the way in which the abstractions are factored is fundamentally broken. Merkuro, unless it takes an inordinate amount of responsibility and actually redesigns the backend is liable to be a dumber version of KMail, plagued with the same problems, and having few if any of the positives, including the mail filters.

And this isn't rocket science. Apple Mail has existed in its present form for the past decade, with few if any changes, yet it offers very similar UI convenience with none of the fuss. Given that emails are the most widely used form of communication, ubiquitous, unchanging, open and largely standardised, how the bloody hell do we still have these early teething issues in a program that has been the exact same since I was a university student.

This is perhaps a needlessly painful point, and I have no idea why this happened the way it happened and didn't happen any other way.

We have many browser front ends, one back end, and mostly no agreement on why this terrible state of affairs erupted on the scene. Probably because the Web is a hodgepodge of barely standard code. Perhaps because the early web had decided to eschew the Unix approach for things and directly embed a JavaScript interpreter into the browser and couple it tightly to the layout engine.

That is beside the point. Currently, Falkon is the closest thing to an official KDE browser. It has a plugin system, but no clear way of writing one, and even simple things as integrating KeePassXC into it seem to be problematic. It is untenable, and while I would agree that writing a browser from the ground up would be too much hassle, I don't want people to do that. Write a version of QuteBrowser that doesn't rely on modal editing⁴. It's just that even Falkon to a large extent feels out of place on KDE. It doesn't feel the same way e.g. Elisa or KTorrent feel, and isn't certainly nearly as polished as Kate or Dolphin.

I wish we had a revival of konqueror, because the idea of a single purpose application that can render both file systems and browse the web is ideal. The main issue is that I now believe that it would be taken to mean to write a file manager in Electron.

I want to round off this section with a discussion of an example of almost all of the lessons applied. Dolphin is a remarkable application that brings many of the things that make KDE – KDE, to the forefront and can be considered by many to be KDEs killer app.

Dolphin is a file manager that fundamentally understands that you want to manage files. It's not quite the swiss army knife that konqueror used to be, but that is for the better. Konqueror would have been a mediocre browser and trying to make it passable would have pulled resources away from making it a good file manager. And there's a lot to Dolphin.

Want to have a UI that resembles YouTube with local videos, you can do it, just crank up the preview sizes. Want to make things as clear as a table, sure, there's that view too. OK, how about features that other file managers don't have? Well, Dolphin and Finder are to my knowledge the only two that also preserve the settings on a per-directory basis. Certainly the GTK file managers could do the same, but we don't assign credit based on hypotheticals. While it is very much within our power to detect radical changes in the colour palette, which could give us more insight, alas, this is something forlorn from the days of moodbars.

Then there's grouping and sorting. Far and away the best feature of Dolphin, that I believe could be made even better. Search is wonderful, especially given that it's indexed search. Network is not ideal, but it isn't terrible either. The one place I would give Dolphin a negative assessment is its support for APFS devices and thus synching to IOS, but that is neither here nor there. GVFS is a gnome-only technology and there hasn't been a Qt reimplementation for a decade.

Dolphin thoughtfully includes multiple rename, it reads tags for you, and it allows you to both use it as a multi-window application as well as a so-called double-decker. I don't have a `konsole` hotkey in KDE, because I often use Dolphin as a front-end for Konsole that allows me to avoid having to write ls half the time.

Anything else? Well, it acts as a decent Git front-end especially if you have configured both GPG and SSH to use the secret service. It lets you edit files as root, compress and decompress archives, copied a piece of text off the internet, fine paste it in and give it a name.

Oh and did I mention that it can use tags? That's a feature that can save people a lot of headache, as anyone who has used tags on Mac OS can attest to.

This is a program that I wish all KDE programs were similar to. In some ways some of them are already like Dolphin, but a lot of them require a bit more work.