- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
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.
You must log in or # to comment.
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:
I put roughly 200 hours into this (largely due to not being familiar with the codebase and technologies involved beforehand)
…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:
-
None of the submitted code is AI generated. I wrote all of it myself (largely by copying existing code).
-
I used OpenAI Codex in the following ways:
- I used it to generate a quick prototype to give me an idea of where to start. The prototype was MUCH more limited and I rewrote it from scratch (i.e. none of the code submitted here is from there).
- I used it to help me with debugging/understanding some of the stuff new to me (e.g. how does a value get to QML, wayland protocols, understanding crashes, …).
- I used it to review the code before submitting it (in addition to manually reviewing it myself). It caught a few minor issues.
- I used it to write a “touchpad simulator” patch that I used for testing touchpad gestures (not submitted).
YMMV on what side of vibe coding that usage falls.
This just sounds like a professional using a tool.
Big caveat there that “AI” still makes stuff up out of the blue, despite being ostensibly trained on “all of human knowledge”. And this guy seems to have used its generated code accordingly to better apply his PHP skills to C++.
You can probably tell I disagree strongly with “AI” being called “just a tool” 😛
Tools giving incorrect answers isn’t some new thing that AI delivered.
AI makes stuff up and random dude on Stackoverflow posts incorrect answers. I see no difference here.
This programmer used it the same way I do. As a tool. It’s a great tool; I find it hard to go back to being without it.
The incorrect answer on Stackoverflow can be downvoted and commented by the community. With a LLM the incorrect answer is perfectly formulated and you’re alone to recognize it. I’ll favor a large community’s advice (cultural quriks and all) over a LLM’s any day.
No one said AI is “just a tool”.
But it can also be a tool, when used correctly.Nope. We all know the phrase “if it’s free, you’re the product”. In one of his non-offensive moments, RMS said that social media users are really “the used”.
Under the current paradigm, the “AI” user is the real tool.
-
If it works, does it really matter if it was vibe-coded? Sometimes, people use tools correctly.
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.
I think what you’re favorably describing stops being “vibe-coding” and starts simply being “coding with LLM assistance”. And I suspect most people in this thread railing against vibe-coding are much less hostile to LLM assistance. In any case, I don’t think saying that people “should start accepting this fact” will convince anyone that wasn’t already, especially if you call it all “vibe coding”.
Yeah, I happen to call both the same and I stopped arguing with the anti-LLM fanatics, as it probably felt the same during industrialization when people were still thinking that “my manual labor will survive no matter what” and then just went bankrupt.
But you are definitely right at this.
Implementing it there would have required violating the EWMH specification, which has no concept of multiple virtual desktops being active at the same time.
So implementing something unspecified is equal to a violation? Weird math.
It’s more that compositors (picom, xcompmgr) and window managers are extremely complex, and adding that feature in could have much larger impacts than just the functionality itself, e.g. security context implications, task scheduling, rendering pipeline issues, etc. Wayland actually combines the compositor and WM, so it’s more readily extensible than X11.
