I spent the morning trying to work out why all the Electron applications on my desktop (vscodium, the Signal client …) were once-a-fuc•ing-gain showing me clunky, foreign file-open and file-save dialogues (presumably from gtk) instead of correctly showing KDE's dialogues via the very-cursed XDG-desktop-portal mechanism.
I'm on Gentoo. Had I, perhaps, broken something?
Nope. It's just yet another regression up-stream, in Electron:
- https://github.com/microsoft/vscode/issues/231173#issuecomment-2410885232
- https://github.com/electron/electron/issues/43819#issuecomment-2379445244
- https://github.com/flatpak/xdg-desktop-portal/issues/1445#issuecomment-2379375660
- https://github.com/flathub/org.signal.Signal/issues/719
Once again, despite knowing that nobody has support for something because that thing has not been released as stable at all, yet, the whole Electron stack follows the belief that it's perfectly OK to release a change that depends on that thing and, without it, breaks every KDE user's desktop integration.
Then they blame it on xdg-desktop-portal not having released, yet. And won't roll the change back because December is their "quiet month" – neither will they fix it nor make a work-around, seemingly.
Anyway. Writing this post has served to exhaust my ire. One day, we'll see the back of Electron for good – I can only hope!
Let it also serve as a PSA: don't bother trying to work out if you've accidentally broken something on your Linux desktop – particularly if you're on Gentoo, Arch, Slackware or other hacker-friendly distribution. It's not you. It's not your system. It's just fuc•ing Electron – again!
If Emmet/keymapping is important, then https://zed.dev/ is the only editor that matches VSCodium as far as I know.
Zed is very interesting. I know it.
Very recently, I found a fork of Zed that gutted the AI Assistant integration and Telemetry. I forked that, myself, and took it further: gutting automatic updates, paid feature-gating, downloading of executable binaries and runtimes like Node.js (for extensions that don't compile to WASI), integration with their online services, voice-calling, screen sharing, etc.
My branch ended up down 140 000 lines[^1] of code and up less than 300! It was educational and the outcome was absolutely brilliant, to be fair. In all honesty, forking it and engaging in this experiment took less than 24 hours even though I restarted three times, with different levels of "stringency" in my quest.
[^1]: No word of a lie! The upstream repo is well over 20k commits and over 100 MB in volume. Zed is not a nice, small, simple code-base: it is VAST and a huge percentage of that is simply uninteresting to me.
This experiment was very realisable. Forking Zed and hacking on it was quite possible – the same cannot be said for just "forking Electron" or "forking VS Code" or even getting up to speed on those projects to the point of being able to fix the underlying issues (like this OP) and submit merge-requests to those projects. They have a degree of inscrutability that I absolutely could overcome but would not, unless I was paid to at my usual rates. (I have two decades of professional development experience.)
I shelved the effort – for the time being – for a few reasons I don't particularly want to extenuate, today, but I shall continue to follow Zed very closely and I truly, deeply hope that there is a future in which I see hope (and, thus, motivation) in maintaining a ready-to-go, batteries-included, AI-free, telemetry-free, cloud-free fork.
Part of maintaining a fork would include sending merge-requests upstream even though I should hardly expect that my fork would be viewed favourably by the Zed business. But, from what I can tell, Zed seem to act true to the open-source principles – unlike many other corporate owners of open-source projects – and I see no reason (yet) to believe they would play unfairly.