A new virtual machine manager called Karton is being developed specifically for the KDE Plasma desktop, aiming to offer a seamless, Qt-native alternative to GNOME-centric tools like GNOME Boxes. Spearheaded by University of Waterloo student Derek Lin as part of Google Summer of Code 2025, Karton uses libvirt and Qt Quick to build a user-friendly, fully integrated VM experience, with features like a custom SPICE viewer, snapshot support, and a mobile-friendly UI expected by September 2025. Neowin reports: To feel right at home in KDE, Karton is being built with Qt Quick and Kirigami. It uses the libvirt API to handle virtual machines and could eventually work across different platforms. Right now, development is focused on getting the core parts in place. Lin is working on a new domain installer that ditches direct virt-install calls in favor of libosinfo, which helps detect OS images and generate the right libvirt XML for setting up virtual machines more precisely. He's still refining device configuration and working on broader hypervisor support. Another key part of the work is building a custom SPICE viewer using Qt Quick from scratch: If you're curious, here's the list of specific deliverables Lin included in his GSoC proposal, though he notes the proposal itself is a bit outdated [...]. For those interested in the timeline, Lin's GSoC proposal says the official GSoC coding starts June 2, 2025. The goal is to have a working app ready by the midterm evaluation around July 14, 2025, with the final submission due September 1, 2025. You can learn more via KDE.org.

Read more of this story at Slashdot.

With its Start menu-style application launcher and its bottom-of-the-screen taskbar, KDE Plasma is a "nice" and "traditional" desktop environment that's "also highly customizable," notes It's FOSS News. But there's a change coming... In contrast to other desktop environments, KDE offers a long-term support release (LTS) of Plasma, where bug fixes and security updates are provided for an extended period, with no new major changes being introduced. However, that is no longer the case now. Shared by Nate Graham, a prominent contributor within the KDE community, KDE has decided to stop working on LTS releases of Plasma, shifting its focus on extending support for the bug-fix and feature releases instead. The reasoning behind this move is multi-faceted, with factors such as inconsistent expectations from the community, developers' reluctance to work on older versions, and the lack of consistency in LTS support for Frameworks and Gear apps... I believe this move will provide Plasma users with a better Linux desktop experience, thanks to the extended bug-fix period, which will enhance the stability of each release. From Graham's blog post: It's no secret that our Plasma LTS ("Long-Term Support") product isn't great. It really only means we backport bug-fixes for longer than usual — usually without even testing them, since no Plasma developers enjoy living on or testing old branches. And there's no corresponding LTS product for Frameworks or Gear apps, leaving a lot of holes in the LTS umbrella. Then there's the fact that "LTS" means different things to different people; many have an expansive definition of the term that gives them expectations of stability that are impossible to meet. Our conclusion was that the fairly limited nature of the product isn't meeting anyone's expectations, so we decided to not continue it. Instead, we'll lengthen the effective support period of normal Plasma releases a bit by adding on an extra bug-fix release, taking us from five to six. We also revisited the topic of reducing from three to two Plasma feature releases per year, with a much longer bug-fix release schedule. It would effectively make every Plasma version a sort of mini-LTS, and we'd also try to align them with the twice-yearly release schedules of Kubuntu and Fedora. However, the concept of "Long-Term Support" doesn't go away just because we're not giving that label to any of our software releases anymore. Really, it was always a label applied by distros anyway — the distros doing the hard work of building an LTS final product out of myriad software components that were never themselves declared LTS by their own developers. It's a lot of work. So we decided to strengthen our messaging that users of KDE software on LTS distros should be reporting issues to their distro, and not to KDE. An LTS software stack is complex and requires a lot of engineering effort to stabilize; the most appropriate people to triage issues on LTS distros are the engineers putting them together. This will free up time among KDE's bug triagers and developers to focus on current issues they can reproduce and fix, rather than wasting time on issues that can't be reproduced due to a hugely different software stack, or that were fixed months or years ago yet reported to us anyway due to many users' unfamiliarity with software release schedules and bug reporting.

Read more of this story at Slashdot.