KDE Archive
I love the Kate Text editor. I use it for pretty much all the programming projects I do. Kate has been around for long time now, about 20 years! At least earliest blog post for it I could find was written in 2004. I wanted to go over my workflow with it, why I like it so much and hopefully get more people to try it out. ↫ Akseli Lahtinen Programmers and developers tend to be very set in their ways and have their preferred workflows – which profession doesn’t, honestly – and since there’s such a wide variety of developer and programming tools out there, it feels like every single developer’s workflow and setup is entirely unique. Akseli Lahtinen, KDE developer and allround awesome person, details his setup using Kate, the venerable and feature-rich text editor from the KDE project. As someone who can’t program, I can’t really compare his workflow to my own, but what I found interesting while reading his post is that there’s quite a bit of overlap between my previous work as a translator and his work as a developer. While the contents of each individual view inside his Kate window are obviously different, the setup of windows and tools I had when translating looked very similar. This shouldn’t be surprising to me – after all, both translating and developing requires multiple work surfaces, language plugins, formatting tools, tons of keyboard shortcuts, and a whole load of browser tabs, PDF files, and other documents to find just the right translation or the perfect term, as well as a ton of background to make sure you understand the topic you’re translating about. Y’all have no idea how much I know about the deepest complex inner-workings and processes of some of the largest organisations in the world, just because I needed to study them and had access to their internal documentation and software. I also read and studied way too many complex contracts, European law, and technical studies into medicine and healthcare treatments, and I guess developers and programmers do the same thing – just focusing on different subjects. What’s the best way to do this thing in the programming language I’m using? How does this library I want to integrate work? What are the API endpoints for this service I want to use? It’s really not that different from translating, and that never really dawned on me until now.
KDE’s login manager, SDDM, has its share of problems, and as such, a number of KDE developers are working on replacement to fix many of these long-standing issues. So, what exactly is wrong with SDDM as it exists today? With SDDM, power management is reinvented from scratch with bespoke configuration. We can’t integrate with Plasma’s network management, power management, volume controls, or brightness controls without reinventing them in the desktop-agnostic backend. SDDM was already having to duplicate too much functionality we have in KDE, which was very frustrating when we’re left maintaining it. ↫ David Edmundson On top of that, theming is also a big issue with SDDM, as it doesn’t adopt any of the existing Plasma themes, wallpapers, and so on, forcing users to manually makes thse changes for SDDM, and forcing theme developers to make custom themes just for SDDM instead of it just adopting Plasma’s settings. The new login manager they’re working on will instead make use of existing Plasma components and be brought up like Plasma itself, too. For now, the SDDM replacement is roughly at feature parity with SDDM, but it’s by no means ready for widespread adoption by distributions or users. Developers interested in trying it out can do so, though, and as it mostly looks like the existing default SDDM setup, you won’t even notice anything in day-to-day use.
One of the biggest behind-the-scenes changes in the upcoming Plasma 6.4 release is the split of kwin_x11 and kwin_wayland codebases. With this blog post, I would like to delve in what led us to making such a decision and what it means for the future of kwin_x11. ↫ Vlad Zahorodnii For the most part, this change won’t mean much for users of KWin on either Wayland or X11, at least for now. At least for the remainder of the Plasma 6.x life cycle, kwin_x11 will be maintained, and despite the split, you can continue to have both kwin_x11 and kwin_wayland installed and use them interchangeably. Don’t expect any new features, though; kwin_x11 will get the usual bug fixes, some backports, and they’ll make sure it keeps working with any new KDE frameworks introduced during the 6.x cycle, but that’s all you’re going to get if you’re using KDE on X11. There’s one area where this split might cause problems, though, and that’s if you’re using a particular type of KWin extension. While KWin extensions written in JavaScript and QML are backend agnostic and can be used without issues on both variants of KWin, extensions written in C++ are not. These extensions need to be coded specifically for either kwin_x11 or kwin_wayland, and with Wayland being the default for KDE, this may mean some of these extensions will leave X11 users behind to reduce the maintenance burden. It seems that very few people are still using KDE on X11, and kwin_x11 doesn’t receive much testing anymore, so it makes sense to start preparations for the inevitable deprecation. While I think the time of X11 on Linux has come and gone, it’s unclear what this will mean for KDE on the BSDs. While Wayland is available on all of the BSDs in varying states of maturity, I honestly don’t know if they’re ready for a Wayland-only KDE at this point in time.
Speaking of KDE, Plasma 6.3 has been released. It brings with it a ton of improvements aimed at digital artists, such as much improved management and configuration of drawing tablets. You can now map an area of the tablet’s surface to a part of the screen, change the functions of stylus buttons, customise the pressure curve and range of a stylus, and much more. The entire settings panel for drawing tablets has also been redesigned to make it easier to find what you’re looking for. Plasma 6.3 also completely overhauls KWin’s fraction scaling. Fractional scaling in KWin will not try to snap everything to your display’s pixel grid, to reduce blurriness and make everything look sharper. KWin’s zoom effect also makes use of these improvements, making for a pixel-perfect zoom feature with a pixel grid overlay, which is great for artists and designers. This will be a very welcome improvement for people using e.g. 125% or 150% scaling on their displays. Hardware monitoring is much improved too, with System Monitor showing more information while using fewer resources, and KDE users on FreeBSD can now see GPU statistics too. There’s also a ton of small additions that are still quite welcome, like opening the menu editor instead of a properties dialog when clicking on Edit Application in a launcher menu’s context menu, the ability to clone panels, an option to turn of symbolic icons in Kickoff, a “Show Target” option in the context menu of symbolic links, and a lot more. KDE Plasma 6.3 will find its way to your distribution of choice soon enough.
One of the major issues with KDE’s styling system is the fact that over the year, it has accumulated four ways of styling applications – which makes themeing and changing aspects of the default theme far more cumbersome than it should be. In fact, with the current version of KDE, it’s effectively impossible to consistently theme the entire KDE desktop, as several parts of it, like Kirigami applications, only inherit parts of the theme you’re applying. It’s a bit of a mess, and KDE is well aware of this. This problem is not new; we already identified it several years ago. Unfortunately, it also is not easy to solve. Some of the reasons it got to this state are simply inertia. Some things like Plasma’s SVG styling were developed as a way to improve styling in an era where a lot of the technologies we currently use did not exist yet. The solutions developed in those days have now existed for a pretty long time so we cannot suddenly drop them. Other reasons are more technical in nature, such as completely different rendering stacks. ↫ Arjen Hiemstra These different rendering stacks form the core of the problem, as they can’t use the same rendering code for everything. Currently, KDE tries to address the problem through a compatibility layer to tie everything together, but it’s not perfect, it has to be maintained, and it means they’re not utilising their rendering stacks to their fullest potential. The solution KDE is working on is called Union. However, there is another option, which is to take a step back and realise that we actually may not even want to share the rendering code, given that they are quite different. Instead, we need a description of what the element should look like, and then we can have specific rendering code that implements how to render that in the best way for a certain technology stack. ↫ Arjen Hiemstra Basically, an input layer will interpret file formats with style descrpitions, while an intermediate layer consists of a library that converts that interpretation into a more abstract description of what needs to be rendered. The final output layer then uses the data from the intermediate layer to tell the rendering stacks what to do. By standardising on the input format, say CSS, it’ll be much easier to impement themes or make changes. This effort is still far from done, but they’re making good progress. It ties into the Plasma Next initiative, which is, as the name implies, an effort to make changes to Plasma’s default look and feel.
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.
It seems the GNOME team is getting quite serious about turning GNOME OS into an end-user focused Linux distribution, similar to a project KDE is working on. GNOME OS is GNOME’s development, testing, and QA distribution. It’s not designed to be useful as a general-purpose system, and so it hasn’t been the center of attention. However, that makes it a convenient place to experiment, and ultimately through sheer coincidence the GNOME OS team ended up developing something that follows my vision using the same technology that I was. The only real difference was intent: carbonOS was intended for mass adoption, and GNOME OS was not. In essentially every other aspect, the projects had the same roadmap: following Lennart Poettering’s “Fitting Everything Together” proposal, providing a stock GNOME experience, and even using the same build system (BuildStream). ↫ Adrian Vovk The goal with GNOME OS is to showcase the best GNOME has to offer, built on top of an immutable base system, using Flatpak as the means to install applications. Basically, we’re looking at something very similar to the immutable Fedora GNOME variant, but probably with even less modifications to stock GNOME, and perhaps with few more newer things as default, like perhaps systemd-boot over GRUB. KDE also happens to be working on a very similar project, with many of the same design choices and constraints. I think this is an excellent idea, for both GNOME and KDE. This allows them to offer users a very focused, simple, and resilient way of showcasing the latest and greatest the two desktop environments have to offer, without having to rely on third-party distributions to not make silly choices or mess things up – for which GNOME and KDE developers then tend to take the heat. Systems like these will, of course, also be a great way for developers to quickly spin up the latest stock versions of GNOME and KDE to test their applications. Still, there’s also a downside to having official GNOME and KDE distributions. If users find bugs or issues in these desktop environment when running other distributions, like Fedora or Ubuntu, GNOME and KDE developers may be tempted to just shrug them off and point them to the official GNOME and KDE distributions. It works there, so obviously the cause of the bug lies with the unofficial distribution, right? This may be a tempting conclusion, but may not be accurate at all, as the real cause could still lie with GNOME and KDE. Once such “official” GNOME and KDE Linux distributions exist, the projects run a real risk of only really caring about how well GNOME and KDE work there, while not caring as much, or even at all, how well they run everywhere else. I’m not sure how they intend to prevent this from happening, but from here, I can already see the drama erupting. I hope this is something they take into consideration. Immutable distributions are not for me, since I prefer the control regular Fedora and RPM gives me, and I don’t want to give that up. It also doesn’t help I really, really don’t like Flatpak as it exists today, which is another major barrier to entry for someone like me, and I assume most OSNews readers. However, there are countless Linux users out there who just want to get stuff done with whatever defaults come with their operating system, and for them, this newly proposed GNOME OS and its KDE counterpart are a great choice. There’s a reason Valve opted for an Arch-based immutable KDE distribution for the Steam Deck, after all.
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
The KDE project is currently having its yearly conference – Akademy – and at the conference, the project announced its goals for the coming years. The KDE community has charted its course for the coming years, focusing on three interconnected paths that converge on a single point: community. These paths aim to improve user experience, support developers, and foster community growth. ↫ Farid Abdelnour on the KDE Blogs First, the project intends to make it easier for developers to build KDE applications. They want to do this in various ways, but most notably they want to improve the developer experience for people writing KDE applications in languages other than C++, such as Rust or Python. This is a very welcome goal, as I feel there’s definitely a bit of a lack of new KDE applications, and as any other open source project, KDE can always use more developers. Second, KDE is going to focus on improving the input experience, as in the various ways you interact with your computer. Accessibility, and the more complex input methods people with accessibility needs require, are also part of this goal, but it also covers simpler things like mice with tons of buttons, drawing tablets, 2-in-1 laptops, and so on. I’m assuming this also includes controlling the various RGB stuff found in every keyboard and mouse these days, as this is something KDE has already been making inroads into. The third and final goal is one strongly related to the first goal, as it involves community outreach to attract new contributors. This covers not just individual contributors, but also support from institutions, organisations, and I’m guessing companies, too. With Valve opting for KDE for its Steam Deck, I wouldn’t be surprised to see some more involvement from that direction, too, which meshes well with the input goal mentioned above. If you all keep becoming Patreons and donating to us, I might be able to actually go to Akademy next year and be a fly on the wall for some more in-depth reporting from such a conference. I can’t guarantee anything – especially since I have two small children, live far away from everything here in the Arctic, and have serious anxiety problems to take into account, but it’s definitely a goal for me for next year.
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.
After the very successful release of KDE Plasma 6.0, which moved the entire desktop environment and most of its applications over to Qt 6, fixed a whole slow of bugs, and streamlined the entire KDE desktop and its applications, it’s now time for KDE Plasma 6.1, where we’re going to see a much stronger focus on new features. While it’s merely a point release, it’s still a big one. The tentpole new feature of Plasma 6.1 is access to remote Plasma desktops. You can go into Settings and log into any Plasma desktop, which is built entirely and directly into KDE’s own Wayland compositor, avoiding the use of third party applications of hacky extensions to X.org. Having such remote access built right into the desktop environment and its compositor itself is a much cleaner implementation than in the before time with X. Another feature that worked just fine under X but was still missing from KDE Plasma on Wayland is something they now call “persistent applications” – basically, KDE will now remember which windows you had open when you closed KDE or shut down your computer, and open them back up right where you left off when you log back in. It’s one of those things that got lost in the transition to Wayland, and having it back is really, really welcome. Speaking of Wayland, KDE Plasma 6.1 also introduces two major new rendering features. Explicit sync removes flickering and glitches most commonly seen on NVIDIA hardware, while triple buffering provides smoother animations and screen rendering. There’s more here, too, such as a completely reworked edit desktop view, support for controlling keyboard LED backlighting traditionally found in gaming laptops, and more. KDE Plasma 6.1 will find its way to your distribution of choice soon enough, but of course, you can compile and install it yourself, too.
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.
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? ↫ David Edmundson That ‘some damage’ was personal data loss, which is quite something to happen after installing a theme. KDE kind of shot itself in the foot here by having something called ‘global themes’, which is a combination of themes for various elements of the desktop, like the application style, icon theme, cursor theme, colour scheme, and so on, but also things like panel layout and even widgets, applets, and other things that can run code. Some of these global themes use shell scripts to implement the more advanced aspects of their themes, and all these things combined means that global themes installed through KDE’s own built-in theme installer can cause some serious damage. The problem is getting some attention now, and I hope they can find a way to make this process more transparent for end users, so people know what they’re getting themselves into. I’m not advocating for dumbing all this stuff down – this isn’t iOS or whatever – but better communication, perhaps clearer labels and warnings are definitely needed.
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.
KWin now supports ICC profiles: In display settings you can set one for each screen, and KWin will use that to adjust the colors accordingly. The Plasma 6 beta is already shipping with that implementation in KWin, and with a few additional steps you can play most HDR capable games in the Wayland session. ↫ Xaver Hugl I’ll admit colour management and HDR is a bit outside my wheelhouse, but I do know both are essentially vital for quite a few digital professions, and that support for them on Wayland specifically has been subpar or missing entirely. It seems progress is being made on these topics, and that’s good news.
