KDE Archive

It’s no secret that I am very worried about the future of Firefox, and the future of Firefox on Linux in particular. I’m not going to rehash these worries here, but suffice to say that with Mozilla increasingly focusing on advertising, Firefox’ negligible market share, and the increasing likeliness that the Google Search deal, which accounts for 85% of Mozilla’s revenue, will come to an end, I have little faith in Firefox for Linux remaining a priority for Mozilla. On top of that, as more and more advertising nonsense, in collaboration with Facebook, makes its way into Firefox, we may soon arrive at a point where Firefox can’t be shipped by Linux distributions at all anymore, due to licensing and/or idealogical reasons. I’ve been warning the Linux community, and distributions in particular, for years now that they’re going to need an alternative default browser once the inevitable day Firefox truly shits the bed is upon us. Since I’m in the middle of removing the last few remaining bits of big tech from my life, I figured I might as well put my money where my mouth is and go on a small side quest to change my browser, too. Since I use Fedora KDE on all my machines and prefer to have as many native applications as possible, I made the switch to KDE’s own browser: Falkon. What is Falkon? Falkon started out as an independent project called QupZilla, but in 2017 it joined the KDE project and was renamed to Falkon. It uses QtWebEngine as its engine, which is Qt’s version of the Chromium engine, but without all the services that talk to Google, which are stripped out. This effectively makes it similar to using de-Googled Chromium. The downside is that QtWebEngine does lag behind the current Chromium version; QtWebEngine 6.8.0, the current version, is Chromium 122, while Chromium 133 is current at the time of writing. The fact that Falkon uses a variant of the Chromium engine means websites just work, and there’s really nothing to worry about when it comes to compatibility. Another advantage of using QtWebEngine is that the engine is updated independently from the browser, so even if it seems Falkon isn’t getting much development, the engine it uses is updated regularly as part of your distribution’s and KDE’s Qt upgrades. The downside, of course, is that you’re using a variant of Chromium, but at least it’s de-Googled and entirely invisible to the user. It’s definitely not great, and it contributes to the Chromium monoculture, but I can also understand that a project like Qt isn’t going to develop its own browser engine, and in turn, it makes perfect sense for KDE, as a flagship Qt product, to use it as well. It’s the practical choice, and I don’t blame either of them for opting for what works, and what works now – the reality is that no matter what browser you’re choose, you’re either using a browser made by Google, or one kept afloat by Google. Pick your poison. It’s not realistic for Qt or KDE to develop their own browser engine from scratch, so opting for the most popular and very well funded browser engine and strip out all of its nasty Google bits makes the most sense. Yes, we’d all like to have more capable browser engines and thus more competition, but we have to be realistic and understand that’s not going to happen while developing a browser engine is as complex as developing an entire operating system. Falkon’s issues and strengths While rendering websites, compatibility, and even performance is excellent – as a normal user I don’t notice any difference between running Chrome, Firefox, or Falkon on my machines – the user interface and feature set is where Falkon stumbles a bit. There’s a few things users have come to expect from their browser that Falkon simply doesn’t offer yet, and those things needs to be addressed if the KDE project wants Falkon to be a viable alternative to Firefox and Chrome, instead of just a languishing side project nobody uses. The biggest thing you’ll miss is without a doubt support for modern extensions. Falkon does have support for the deprecated PPAPI plugin interface and its own extensions system, but there’s no support for the modern extensions API Firefox, Chrome, and other browsers use. What this means for you as a user is that there are effectively no extensions available for Falkon, and that’s a huge thing to suddenly have to do without. Luckily, Falkon does have adblock built-in, including support for custom block lists, so the most important extension is there, but that’s it. There’s a very old bug report/feature request about adding support for Firefox/Chrome extensions, which in turn points to a similar feature request for QtWebEngine to adopt support for such extensions. The gist is that for Falkon to get support for modern Firefox and Chrome extensions, it will have to go through QtWebEngine and thus the Qt project. While I personally can just about get by with using the BitWarden application (instead of the extension) and the built-in adblock, I think this is an absolute most for most people to adopt Falkon in any serious numbers. Most people who would consider switching to a different browser than Chrome or Firefox are going to need extensions support. The second major thing you’ll miss is any lack of synchronisation support. You won’t be synchronising your bookmarks across different machines, let alone open tabs. Of course, this extends to mobile, where Falkon has no presence, so don’t expect to send your open tabs from your phone to your desktop as you get home. While I don’t think this is as big of an issue as the lack of modern extensions, it’s something I use a lot when working on OSNews – I find stories to link to while browsing on my phone, and then open them on my desktop to post them through the tab sharing feature of Firefox, and

Recently, I’ve been moving away from macOS to Linux, and have settled on using KDE Plasma as my desktop environment. For the most part I’ve been comfortable with the change, but it’s always the small things that get me. For example, the Mail app built into macOS provides an “Unsubscribe” button for emails. Apparently this is also supported in some webmail clients, but I’m not interested in accessing my email that way. Unfortunately, I haven’t found an X11 or Wayland email client that supports this sort of functionality, so I decided to implement it myself. And anyway, I’m trying out Kontact for my mail at the moment, which supports plugins. So why not use this as an opportunity to build one? ↫ datagirl.xyz Writing a Kmail plugin like this feels a bit like an arcane art, because the process is not documented as well as it could be, and I doubt that other than KDE developers themselves, very few people are interested in writing these kinds of plugins. In fact, I can’t find a single one listed on the KDE Store, and searching around I can’t find anything either, other than the ones that come with KDE. It seems like this particular plugin interface is designed more to make it easy for KDE developers to extend and alter Kmail than it is for third parties to do so – and that’s fine. Still, this means that if some third party does want to write such a plugin, there’s some sleuthing and hacking to be done, and that’s exactly the process this article details. In the end, we end up with a working unsubscribe plugin, with the code on git so others can learn from it. While this may not interest a large number of people, it’s vital to have information like this out on the web for those precious few to find – so excellent work.

Entirely coincidentally, the KDE team released Plasma 6.2 yesterday, the latest release in the well-received 6.x series. As the version number implies, it’s not a groundbreaking release, but it does contain a number of improvements that are very welcome to a few specific, often underserved groups. For instance, 6.2 overhauls the Accessibility settings panel, and ads, among other things, colourblindness filters for a variety of types of colourblindness. This condition affects roughly 8-9% of the population, so it’s an important new feature. Another group of people served by Plasma 6.2 are artists. Plasma 6.2 includes a smorgasbord of new features for users of drawing tablets. Open System Settings and look for Drawing Tablet to see various tools for configuring drawing tablets. New in Plasma 6.2: a tablet calibration wizard and test mode; a feature to define the area of the screen that your tablet covers (the whole screen or a section); and the option to re-bind pen buttons to different kinds of mouse clicks. ↫ KDE Plasma 6.2 release announcement Artists and regular users alike can now also enjoy better colour management, more complete HDR support, a tone-mapping feature in Kwin, and much more. Power management has been improved as well, so you can now manage brightness per individual monitor, control which application block going to sleep, and so on. There’s also the usual array of bug fixes, UI tweaks, and so on. Plasma 6.2 is already available in at least Fedora and openSUSE, and it will find its way to your distribution soon enough, too.

Over the decades, my primary operating system of choice has changed a few times. As a wee child of six years old, we got out first PC through one of those employer buy-a-PC programs, where an employer would subsidize its employees buying PCs for use in the home. The goal here was simple: if people get comfortable with a computer in their private life, they’ll also get comfortable with it in their professional life. And so, through my mother’s employer, we got a brand new 286 desktop running MS-DOS and Windows 3.0. I still have the massive and detailed manuals and original installation floppies it came with. So, my first operating system of ‘choice’ was MS-DOS, and to a far lesser extent Windows 3.0. As my childhood progressed, we got progressively better computers, and the new Windows versions that came with it – Windows 95, 98, and yes, even ME, which I remarkably liked just fine. Starting with Windows 95, DOS became an afterthought, and with my schools, too, being entirely Windows-only, my teenage years were all Windows, all the time. So, when I bought my first own, brand new computer – instead of old 386 machines my parents took home from work – right around when Windows XP came out, I bought a totally legal copy of Windows XP from some dude at school that somehow came on a CD-R with a handwritten label but was really totally legit you guys. I didn’t like Windows XP at all, and immediately started looking for alternatives, trying out Mandrake Linux before discovering something called BeOS – and despite BeOS already being over by that point, I had found my operating system of choice. I tried to make it last as long as the BeOS community would let me, but that wasn’t very long. The next step was a move to the Mac, something that was quite rare in The Netherlands at that time. During that same time, Microsoft released Windows Server 2003, the actually good version of Windows XP, and a vibrant community of people, including myself, started using it as a desktop operating system instead. I continued using this mix of Mac OS X and Windows – even Vista – for a long time, while having various iterations of Linux installed on the side. I eventually lost interest in Mac OS X because Apple lost interest in it (I think around the Snow Leopard era?), and years later, six or seven years ago or so, I moved to Linux exclusively, fully ditching Windows even for gaming like four or so years ago when Valve’s Proton started picking up steam. Nowadays all my machines run Fedora KDE, which I consider to be by far the best desktop operating system experience you can get today. Over the last few years or so, I’ve noticed something fun and interesting in how I set up my machines: you can find hints of my operating system history all over my preferred setup and settings. I picked up all kinds of usage patterns and expectations from all those different operating systems, and I’d like to enable as many of those as possible in my computing environment. In a way, my setup is a reflection of the operating systems I used in the past, an archaeological record of my computing history, an evolutionary tree of good traits that survived, and bad traits bred out. Taking a look at my bare desktop, you’ll instantly pick up on the fact I used to use Mac OS X for a long time. The Mac OS X-like dock at the bottom of the screen has been my preferred way of opening and managing running applications since I first got an iBook G4 more than 20 years ago, and to this day I find it far superior to any alternatives. KDE lets me easily recreate a proper dock, without having to resort to any third-party dock applications. I never liked the magnification trick Mac OS X wowed audiences with when it was new, so I don’t use it. The next dead giveaway I used to be a Mac OS X user a long time ago is the top bar, which shares quite a few elements with the Mac OS X menubar, while also containing elements not found in Mac OS X. I keep the KDE equivalent of a start menu there, a button that brings up my home folder in a KDE folder view, a show desktop button that’s mostly there for aesthetic reasons, KDE’s global menubar widget for that Mac OS X feel, a system tray, the clock, and then a close button that opens up a custom system menu with shutdown/reboot/etc. commands and some shortcuts to system tools. Another feature coming straight from my days using Mac OS X is KDE’s equivalent of Exposé, called Overview, without which I wouldn’t know how to find a window if my life depended on it. I bind it to the top-left hotcorner for easy access with my mouse, while the bottom-right hotcorner is set to show my desktop (and the reason why I technically don’t really need that show desktop button I mentioned earlier). I fiddled with the hot corner trigger timings so that they fire virtually instantly. Waiting on my computer is so ’90s. It’s not really possible to see in screenshots, but my stint using BeOS as my main operating system back when that was a thing you could do also shines through, specifically in the way I manage windows. In BeOS, double-clicking a titlebar tab would minimise a window, and right-clicking the tab would send the window to the bottom of the Z-stack. I haven’t maximised a non-video window in several decades, so I find double-clicking a titlebar to maximise a window utterly baffling, and a ridiculous Windows-ism I want nothing to do with. Once again, KDE lets me set this up exactly the way I want, and I genuinely feel lost when I can’t manipulate my windows in this

Not everything made by KDE uses C++. This is probably obvious to some people, but it’s worth mentioning nevertheless. And I don’t mean this as just “well duh, KDE uses QtQuick which is written with C++ and QML”. I also don’t mean this as “well duh, Qt has a lot of bindings to other languages”. I mean explicitly “KDE has tools written primarily in certain languages and specialized formats”. ↫ Thiago Sueto If you ever wanted to contribute to KDE but weren’t sure if your preferred programming language or tools were relevant, this is a great blog post detailing how you can contribute if you are familiar with any of the following: Python, Ruby, Perl, Containerfile/Docker/Podman, HTML/SCSS/JavaScript, Web Assembly, Flatpak/Snap, CMake, Java, and Rust. A complex, large project like KDE needs people with a wide variety of skills, so it’s definitely not just C++. An excellent place to start.

KWin had a very long standing bug report about bad performance of the Wayland session on older Intel integrated graphics. There have been many investigations into what’s causing this, with a lot of more specific performance issues being found and fixed, but none of them managed to fully fix the issue… until now. ↫ Xaver Hugl An excellent deep dive into a very annoying problem KWin on Wayland running on older Intel hardware was facing. It turns out the issue was related to display timings, and older Intel hardware simply not being powerful enough to render frames within the timing window. The solution consisted of a various smaller solutions, and one bigger one: triple-buffering. The end result is a massive performance improvement for KWin on Wayland on older Intel hardware. This detailed post underlines just how difficult it is to simply render a bunch of windows and UI elements on time, without stutters or tearing, while taking into account the wide variety of hardware a project like KDE Plasma intends to run on. It’s great to see them paying attention to the older, less powerful systems too, instead of only focusing on the latest and greatest like Apple, and recently Microsoft as well, do.

Kate, KDE’s programming-focused text editor, is, of course, a Qt application, and is also available on a variety of other platforms. Christoph Cullmann, one of the developers of Kate, published a short blog post with screenshots of Kate running on the three biggest platforms – Linux/BSD, Windows, and macOS. Sadly, while Haiku gets a mention, there’s no screenshot of the Haiku version of Kate. Still, it’s interesting to see the family resemblance.

With KDE’s 6th Mega Release finally out the door, let’s reflect on the outgoing Plasma 5 that has served us well over the years. Can you believe it has been almost ten years since Plasma 5.0 was released? Join me on a trip down memory lane and let me tell you how it all began. This coincidentally continues pretty much where my previous retrospective blog post concluded. ↫ Kai Uwe It took them a few years after the release of Plasma 5.0, but eventually they won me over, and I’m now solid in the KDE camp, after well over a decade of either GNOME or Cinnamon. GNOME has strayed far too much away from just being a traditional desktop user interface, and Cinnamon is dragging its heels with Wayland support, but luckily KDE has spent a long time now clearing up so many of the paper cuts that used to plague them every time I tried KDE. That’s all in the past now. They’ve done a solid job cleaning up a lot of the oddities and inconsistencies during Plasma 5’s lifecycle, and I can’t wait until Fedora 40 hits the streets with Plasma 6 in tow. In the desktop Linux world, I feel KDE and Qt will always play a little bit of second fiddle to the (seemingly) much more popular GNOME and GTK+, but that’s okay – this kind of diversity and friendly competition is what makes each of these desktops better for their respective users. And this is the Linux world, after all – you’re not tied down to anything your current desktop environment does, and you’re free to switch to whatever else at a moment’s notice if some new update doesn’t sit well with you. I can’t imagine using something like macOS or Windows where you have to just accept whatever garbage they throw at you with nowhere to go.

In order solve that problem, we started looking for some options and the most obvious one was QtQuick. It’s a quite powerful framework and it’s already used extensively in Plasma. So, in Plasma 5.24, we introduced basic support for implementing kwin effects written in QML and even added a new overview effect. Unfortunately, if you wanted to implement a QtQuick-based effect yourself, you would still have to write a bit of C++ glue yourself. This is not great because effects that use C++ are a distribution nightmare. They can’t be just uploaded to the KDE Store and then installed by clicking “Get New Effects…”. Furthermore, libkwin is a fast moving target with lots of ABI and API incompatible changes in every release. That’s not good if you’re an effect developer because it means you will need to invest a bit of time after every plasma release to port the effects to the new APIs or at least rebuild the effects to resolve ABI incompatibilities. This has been changed in Plasma 6.0. In Plasma 6, we’ve had the opportunity to address that pesky problem of requiring some C++ code and also improve the declarative effect API after learning some lessons while working on the overview and other effects. So, enough of history and let’s jump to the good stuff, shall we? ↫ Vlad Zahorodnii Making it easier to write things like Plasma widgets and Kwin effects is always desirable, and making them easier to distribute is only icing on the cake.

KDE Plasma 6 has been released – and this is an important release with two massive low-level stack upgrades. With Plasma 6, our technology stack has undergone two major upgrades: a transition to the latest version of our application framework, Qt, and a migration to the modern Linux graphics platform, Wayland. We have done our best to ensure that these changes are as smooth and unnoticeable to the users as possible, so when you install this update, you will see the same familiar desktop environment that you know and love. But these under-the-hood upgrades benefit Plasma’s security, efficiency, and performance, and improve support for modern hardware. Thus Plasma delivers an overall more reliable user experience, while paving the way for many more improvements in the future. Aside from this, there’s so much in this release it’s hard to know where to begin. My favourite is the overhaul of KDE’s default Breeze theme, which now uses far, far fewer frames, meaning there’s fewer borders-on-borders. Spacing has also been made more consistent within Breeze. Both of these efforts make KDE applications and UI elements look a bit less cluttered and busy, which, while easily missed if you don’t look for it, certainly cleans things up nicely. Another important improvements is the addition of support for HDR displays and colour management. Plasma on Wayland now has partial support for High Dynamic Range (HDR). On supported monitors and software, this will provide you with richer and deeper colors for your games, videos, and visual creations. Set an ICC profile for each screen individually and Plasma will adjust the colors accordingly. Applications are still limited to the sRGB color space, but we are working on increasing the number of supported color spaces soon. To improve Plasma’s accessibility, we added support for color blindness correction filters. This helps with protanopia, deuteranopia or tritanopia. Of course, this release is accompanied by updates to a large number of KDE applications, and several default settings in KDE have been changed as well to better suit what most users would expect. Plasma Search has been overhauled as well, making it faster and less resource-intensive, and giving users the ability to better control how search results are displayed. There’s a lot more here, so be sure to dive into the release announcement, KDE Plasma 6 will find its way to your distribution or operating system of choice over the coming weeks and months.

Yep you read that right, we’ve decided to throw the lever and go Wayland by default! The three remaining showstoppers are in the process of being fixed and we expect them to be done soon–certainly before the final release of Plasma 6. So we wanted to make the change early to gather as much feedback as possible. Excellent news. Of course, distributions will still be able to opt for the unmaintained, deprecated X.org if they want to, but most distributions will opt for Wayland, as all the major ones have been doing for a while now.

Another week of KDE Plasma 6 big smashing and new features, and it’s a long list of good stuff. The biggest news this week: The Overview and Desktop Grid effects have been merged together into one, with fluid and natural-feeling touchpad gestures to transition between all states. It’s really awesome work, and also fixed a ton of open bug reports! There’s quite a few other things in here, such as indicators for when the camera is in use in the system tray, fixes for floating panels, improved systemd integration so killing processes when logging out should be less buggy, and a whole lot more.

A month has passed since the last Plasma 6 status update, so it’s time for another one! First, what you’ve all been waiting for: a release date! We’ve decided that Plasma 6 will be released in early February of 2024. We don’t have a specific day targeted yet, but it’ll be in that timeframe. I’m feeling quite confident that the release will be in excellent shape by then! It’s already in good shape right now. 5 months should provide enough of a runway for a solid final release. Following the development of Plasma 6 has been an interesting ride, and it seems it’s in a good state – and these five months will make it even better.

For KDE Plasma 6, the KDE team intends to remove a number of old features and bits of code that haven’t been touched in ages or simply don’t make sense to keep around. Most of it is truly stuff few will use, but there’s some interesting ones in there that might make some users a little sad. First, they intend to remove the icon view from the settings application, leaving only the sidebar view that’s been the default for a while now. This one bugs me, because I only use the icon view – it’s what I use on every other platform, too. The sidebar view might be more modern, but I find it difficult to find anything in there. The reasoning behind its removal is that the code has simply not been touch in a while, and features like search highlighting aren’t even available in icon view. Second, they’re removing Unsplash integration, which kind of sucks. The reason? AI. This one is quite sad, as no one wanted to remove it. Alas, we had to because Unsplash changed their terms of service to preclude Plasma’s usage of it, as a way of fighting automated data scrapers for AI training models. With a heavy heart, we removed it. So the next time anyone asks you what AI can do for humanity, now you have a concrete answer: prevent Plasma 6 from shipping an Unsplash Picture of the Day wallpaper plugin. Thanks, AI! Third, and I love this one, they’re finally fixing the weird issue where the selected Plasma style would overwrite some of the icons from the system-wide icon theme. This feature originally served the purpose of allowing monochrome icons to be set in Plasma, but this is simply no longer needed and only leads to confusion. There’s a lot more that’s being cleaned up and removed, so take a peek at the list to see if your favourite obscure feature is getting cut. Of course, as Nate Graham notes, if you wish for some of these features to stay – you can pick up the code and work on it.