Back in 2005, a bug report was filed by Kjetil Kjernsmo, then running KDE 3.3.2 on Debian Stable. He wanted the ability to have each connected screen show a different virtual desktop independently, rather than having all displays switch as one unit.
Over the years, over 15 duplicate reports piled onto the original as more people ran into the same wall. And that’s not a surprise, because multi-monitor setups have become increasingly common.
The technical reason why this issue stayed open this long comes down to X11. Implementing it there would have required violating the EWMH specification, which has no concept of multiple virtual desktops being active at the same time.
The KWin maintainer Martin Flöser had said as much in 2013, effectively ruling it out for the entire KDE 4.x series. The only realistic path was through Wayland, and that path needed someone willing to actually walk it.
Someone finally did. The feature has now landed in KWin’s master branch and is set for a Plasma 6.7 introduction.
It’s great those long time issues are solved, but after reading the article I can’t help but wonder if the person vibe-coded it or something. I am a bit experienced on PHP too and know a tiny bit of C but still find C++ so incredibly daunting and complex I can’t even imagine tackling such a serious bug on it all by myself
I understand the scepticism, it’s easy to be wary of assisted coding as a gut reaction these days. However, the programmer replied to his own merge request:
…and I find it hard to believe a vibe coder would bother prompting his magic eightball for that long? Maybe that’s my personal prejudice against that particular set of (often wannabe) programmers showing.
There’s also an “AI” disclosure in the original merge request that says:
YMMV on what side of vibe coding that usage falls.
This just sounds like a professional using a tool.
If it works, does it really matter if it was vibe-coded? Sometimes, people use tools correctly.
If you want secure, reliable, and maintainable code, very much yes.
Yes, it does. Sure it works, but at what cost to security and actual human understanding?? RollerCoaster Tycoon works and I’m not saying its insecure or vibe coded, but it’s written in friggen assembly!
The problem isn’t the vibecoding inherently, it’s the people that are doing it. Vibecoding just enables them to exist.
They have no concept of what it means to produce general software for actual users using different setups. They generally have little patience and will abandon their projects very quickly. They are completely reliant on the models to fix any problems (or add features), so anything that, for whatever reason, a model can’t fix will remain broken.
Look at this vibe coded app and thread on reddit for just one example https://old.reddit.com/r/selfhosted/comments/1rckopd/huntarr_your_passwords_and_your_entire_arr_stacks/
Was that vibe coded tool used correctly? Done, does not mean good, or safe, or even usable.
No, it does not. You can write good code with LLM. The tool is not the problem here, the user is. Inexperienced people think they can just develop something in a weekend and indeed, it looks good on the surface. But this leads then to the thing you describe. But if you carefully implement features including all tests, nothing is wrong with vibe coding. And people should start accepting this fact instead of fighting it based on bad examples.
Your Rollercoaster Tycoon example is a bit odd, since coding a whole game in assembly indicates deep understanding of what you’re doing, whereas the problem with vibe coding is that it requires only the shallowest understanding. Unless I’m misunderstanding and that was your point.
There may be a maintainability issue with both, but for a different reason in each case.
Sure, but I’m going to guess KDE devs didn’t blindly accept the merge request.
Vibe coding is not a correct use of ai tools. You can’t trust the code if the developer doesn’t understand it.
Why are we assuming he didn’t and it must be “AI”?