KDE Archive
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.
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.
KDE Gear 23.08.1 comes only three weeks after KDE Gear 23.08 and fixes various issues in several KDE apps, including the Dolphin file manager which now exports the copy location path with native separators on copy operations, and the Gwenview image viewer whose navigation works better with side mouse buttons. The Kdenlive video editor received quite some attention in this release with fixes for a possible crash in the audiolevel widget, broken audio channel setting when opening an existing project file, incorrect saving of default audio channels for a project, a crash on subclip transcoding, and extracting of audio multi-stream clips. There’s way more bug fixes and improvements than these. As always, KDE Gear 23.08.1 will make its way to your distribution soon enough, and of course, if you’re crazy, you can compile it yourself as well.
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.
The KDE project just finished up its 2023 developer sprint, and with Plasma 6 development being in full swing – which encompasses moving to Qt 6 – there’s some major announcements here. As a result, we advanced a number of topics that had been stuck for a while. A major area of my focus in this respect became “Better default settings”. The 5 -> 6 transition is the perfect time to make significant changes to the default settings in a way that improve the UX out of the box. The two biggest changes to KDE’s default settings will be moving from single-click to open a file, to double-clicking. Single-clicking to open has been a KDE staple for a long time, but it’s the exact opposite of literally every other major environment, so it makes sense to align this basic interaction with people’s expectations. Of course, this is KDE, so it’ll be a toggle in the same way it is now. The second major change is Wayland by default. While X.org will, of course, still work and be available to distributions and users, Wayland will be KDE’s official recommendation from here on out. With X.org development having pretty much halted completely, and quite a few major distributions now defaulting to Wayland, this is the right move to make. For all the Wayland haters – feel free to donate your time and expertise to X.org development, because no one else is. There’s a few other cool changes coming up, such as the floating panel by default, the accent colour being used in the top parts of windows, and more.
KDE Plasma 5.27, a Long Term Support release and the final release in the Plasma 5 series which is based on Qt 5, has been released. Plasma 5.27 brings exciting new improvements to your desktop, and the first thing you’ll notice when firing up Plasma is our new Konqi-powered wizard which will guide you through setting up the desktop. Other big new features include a window tiling system, a more stylish app theme, cleaner and more usable tools, and widgets that give you more control over your machine.
Guest post by