KDE Is Getting a Native Virtual Machine Manager Called 'Karton' (neowin.net) 37
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.
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.
The letter K (Score:1)
Re: (Score:2, Insightful)
It's an impediment to new users.
If I go to Accessories, there's no Calculator. I need to read down to KCalc.
Imagine if MacOS had MCalculaor, MPages, MStickies or whatever. The iEverything is bad enough.
Or WNotepad etc on Windows.
It just doesn't make sense to me. As a development code name, of course, no limits.
Re: (Score:1)
Shocked, I say.
Re: The letter K (Score:5, Informative)
Right click the menu/launcher and choose configure. "Show applications as..." defaults to name only, but you can choose description only (ie "calculator") or description (app name) or app name (description) where the parentheses are a minor heading so little under the main displayed thing. Changing the main displayed item also sorts the menu alpha by that so calculator would be under C not K for kcalc.
Re: (Score:2, Informative)
Sorry to the moderator who gave me "overrated" for posting the solution to the exact thing that was annoying him. In the future, I will not help. Noted.
Re: (Score:2)
Thanks for your suggestion. Don't bother about that moderation- could be a stuck mouse wheel. Let the meta-moderation process get him
Re: (Score:3)
I hit the super key, type in "calc" and it shows me several available calculators, including kcalc which happens to be the the first and highlighted choice, and even says under it "Scientific Calculator." I doubt any Windows user would have a problem with that.
The K stuff has never bothered me. I use a mix of Mate, Gnome, and KDE apps. I don't want to learn a new desktop paradigm, so Gnome is out. I used to use Mate, but wayland support was lacking. I now use KDE Plasma and have no real desire to go bac
Re: (Score:2)
Re: (Score:3)
Also, the fighting game series Mortal Kombat does the same. Is there a link between KKK, KDE and Mortal Kombat? Of course there is, but what is it? What sinister plans are they all hatching? I feel it's all part of a great conspiracy. We must uncover it at once! Let me just get the whiteboard and the newspaper cuttings out.
Re:more to the point (Score:4, Funny)
Ahem, I think you mean Konspiracy.
Re: (Score:3)
I never understood why they called it KCalc, rather than Kalculator or just Kalc.
Re: (Score:2)
The menu has an entry "Calculator (kcalc)" and you can configure if you want it to be "Calculator" or "KCalc (Calculator)" as alternatives.
Re: The letter K (Score:1)
Old habbits (Score:3)
It really was starting to look a little better, but here comes the app-for-that idea-fairy that needs a Kasdf application developed because it either:
1) Wasn't made by us
2) Doesn't have a big enough K
It really is a good idea. Just wtf with the Ks.
And the article reads about GNOME and using boxes to spin up VMs....
No. Not everybody does that. There are already existing programs for that, and they work just fine. Stop with the ecosystem creating bullshit - this should always be a cross platform function not tied to your desktop environment decisions.
Re: (Score:2)
No. Not everybody does that.
I'd argue that literally nobody does that since Boxes has been broken for as long as I can remember.
Pretty sure anyone doing this kind of thing is using virt-manager.
Desperately Needed (Score:5, Informative)
What is desperately needed in this tool is the ability to create a network bridge in a couple mouse clicks using the primary network adapter. I've wanted to transition away from Virtual Box for years now, but bridge networking has held me back.
Virtual Box lets me create a bridge with a simple click on a single combo box. Done. KVM is WAY more complicated, and risks network destruction. The inability to easily create a network bridge is a deal breaker that keeps me (and therefore my clients) on Virtual Box.
Re: Desperately Needed (Score:2)
Re: (Score:2)
Pretty sure bog standard virt-manager and libvirtd does that. I don't recall ever setting up the bridge manually.
Re: (Score:2)
There are a few quirks with the interactions with whatever-your-vomitous-network-configuration-daemon-is, but it's not too terrible.
Re: (Score:2)
Pretty sure bog standard virt-manager does that
Maybe it does it on newer versions, but I never got it working on the version that comes with Kubuntu 20.04 or earlier. I remember the option to bridge being there, but never working.
Re: (Score:2)
It didn't work well for me on Devuan, I don't know why but I had to manually create a bridge. This was true while using both ufw and firewalld.
Re: (Score:2)
True I suppose you can theoretically blow up your network connectivity, but counterpoint - if you're doing this sort of thing via a desktop environment, you're running it on your pc/laptop so it's not quite in the same league of "shit I have no way to remote into this box and no access to the datacenter" uh-o
Re: (Score:1)
Re: (Score:2)
Virt-Manager can do this, but it is also not hard to do yourself.
Add a bride in /etc/network/interfaces
iface br0 inet static
address x.x.x.x # host IP. Do not assign an IP if the host should not be reachable
netmask xx
pre-up ip link add name br0 type bridge
post-down ip link del name br0
auto br0
Then add a network card to the VM and choose "Bridge" and set the devicename to br0.
Why is the GUI the important bit ? (Score:3)
Surely one would write a VM manager with all the features described.
And add a basic GUI on top of it.
Then, if necessary, add other GUIs on top of it, in a variety of flavors.
This is like designing a car and crowing about how it's red, and much better than all those blue cars the other company makes.
Re:Why is the GUI the important bit ? (Score:4, Informative)
As others have mentioned, it has an unfortunate dearth of Ks in its name, which is problematic for certain fanatics.
Re: (Score:2)
Having to tie the GUI to OS is El Stupido! The industry dearly needs a stateful GUI markup standard so we can have a GUI browser that has all the common GUI idioms we know and love [reddit.com] rather than keep mis-inventing them via the JavaScript Framework Sisyphus Cycle or hard-wiring them to the OS.
It wouldn't replace all needs for native GUI's, but a good portion of them, at least for ordinary data-centric CRUD. (Graphics designers and word-processors are probably outside its scope.)
The GUI browser would probably b
Re:Why is the GUI the important bit ? (Score:5, Interesting)
As someone who ran a Slackware desktop personally for 10 years while managing Windows networks, and who now manages Windows clusters (Hyper-V and VMWare until Broadcom went silly)...
A GUI for management is one thing that Windows understands and gets nearly-right. Managing a cluster of VMs with a thousand settings each and exposing them in a GUI is child's play because everything is abstracted to a single visual interface.
By comparison, a CLI interface for managing VMs, containers, etc. is HORRENDOUS. Regardless of the OS. Trying to manage Hyper-V VMs through Powershell alone, for example, is horrible and inefficient.
Some things a CLI is *amazing* for and is my first port of call and I don't even consider using a GUI. Other things a CLI is the worst possible interface for short, quick, simple management of a complex set of resources.
CLI's can be scripted, but many people NEVER script a VM because it's just not necessary. If I worked in CI... yes, I'd want a scriptable CLI interface to do that with as I'd want machines to be built, run and destroyed automatically based on scripted events.
But much of VM management is just having a bunch of machines running on one machine, managing an entire network of servers inside a single interface, and just wanting them to run and change an occasional setting without having to remember obscure commands and select VMs from a long list of identifiers that can only be discovered from the output of another CLI command, and so.
To me, in my daily IT life, a VM manager GUI is the only part I interact with, or need to. I never need to script them and only ever drop to a CLI when there's a GUI option missing. I never deploy Server Core on my machine (I might have it on a server, but that server will actually be managed by somewhere else using the GUI tools).
The VM and container manager people on Linux seem to not care one bit about GUIs, or the UI on the CLI in general. To them, it's an API with a scriptable interface. That's fine. If they're not GUI people, I want them to focus on making the VM manager work to manage VMs.
But as we have always done - the underlying tools and their back-end developers are not the determiners of how the user wants to use their tool. They work differently to almost EVERY other user on the planet. And many of those other users just want a simple GUI.
Think of the cdrecord debacle. For years the author ONLY wanted to allow the CLI tools to accept a full SCSI path, even for things that were never SCSI (e.g. ATAPI interfaces, USB interfaces, etc.). That's fine. I get that. For THEIR purposes. But what happened is that people created a dozen different GUIs over the years to expose that same tool's functionality in a much simpler manner. Select a dropdown box of the available CD recorders. So much simpler.
And the GUI and the underlying tools do not need to be linked whatsoever. It's basically why X / Wayland exist. They are just GUI layers, separate from the underlying mechanisms they employ to do their jobs. It's the bit where Windows FORCED users one way and then realised - the CLI still needs to be accessible.
So the GUI is very important for many users. I count myself among them, and I once operated my network off a single-floppy Linux distribution that I contributed to, with no GUI beyond a simple ASCII menu, used to craft my own AUTOEXEC.BAT to provide a boot menu of a dozen options, and ran Slackware for a decade.
It also doesn't need to - and should not necessarily be written as - part of the underlying software. People who develop and almost exclusively work in CLI tend not to make good GUIs, it's why the entire profession of UI/UX designers exist.
So that the GUI and underlying tools are separate, and the GUI is entirely replaceable and can go out of date, get deprecated, etc. without affecting the tools (and vice versa!) and that a GUI could even manage a dozen different types of VM or container in one interface using lots of different tools that each individually would never care about supporting that particular GUI? That's how it works. Because it works best like that.
I would give my right arm for a decent VM/container GUI that encapsulate all the proxmox / qemu / docker / etc. nonsense into one simple GUI where I never have to remember what obscure command shows me a list of containers, lets me connect to the shell of one and lets me manage and kill it simply.
If anything, it's one of my largest bugbears that I have systems I've deployed where certain software just sucks down a dozen such containers or demands a certain VM technology and I have to learn ALL OF THAT before I can effectively manage a small piece of unrelated software - including how to secure it, how to monitor it, and how to kill / restart / interact with its processes.
FYI, I absolutely hate Docker, purely because of this.
So would I like a separately developer GUI that could be extended and used and work on all those VMs technologies without me ever needing to drop to a console? Damn right I would.
Means "cardboard box" (Score:3)
In German.
Re: (Score:1)
Re: Means "cardboard box" (Score:1)
Re: Means "cardboard box" (Score:2)
Karton in Polish means cardboard box (Score:1)