Linux Roadmap

[mikayla-maki]

This is Zed's official roadmap and progress tracker for porting Zed to Linux.

Contributor Guide

There's a lot of surface area to cover and we would love contributions for anything from fixing a small todo(linux), to adding a large feature. That said, it'd probably be good to check in with us or our community in the #linux-port channel of our official Discord. Once you have a project underway, please open a draft PR with a description and small checklist of what you expect should be done, like so, so we can follow along, make suggestions, etc. If you have code that is stubbed out or out of scope, please mark it with a comment containing todo(linux), so we can search for it later.

To setup your machine to build and run Zed, run or reference the script in script/linux.

TODO

• [x] Implement a UI renderer
• [x] Implement a text system
• [x] Implement a Wayland and X11 client
• [x] Add inotify based file watching
• [x] Add in-app menus and prompts
• [x] Add support for the primary selection buffer
• [x] Integrate with local settings
• [x] Add support for File drag and drop
• [x] Implement the CLI
• [x] Implement IME
• [x] Hook up crash reporting, telemetry, etc.
• [ ] #13714
• [ ] Finalize distribution

[DarkArc]

Switch to Vulkan if it doesn't work out

I hope you are also considering Linux running on older hardware with no or bad Vulkan support. Many hardware-accelerated UIs on Linux such as Firefox or GTK 4 still support OpenGL 3.x.

GTK and Firefox existed before Vulkan.

At this point the oldest cards that support Vulkan (at least for AMD) are roughly 12 years old.

I have doubts that the crossover between people excited about Zed and people trying to run it on hardware that's 10+ years old is going to be very high.

At some point, new things shouldn't be expected to cater to increasingly dated hardware.

[darltrash]

In theory, supporting WebGPU through Dawn would already give enough support for all major platforms under the same rendering codebase but that sounds super messy. I don't exactly know how Zed works nor how the development is structured but I feel like supporting so much rendering apis all at once might be detrimental...

[chiddekel]

2. WebGPU A Taste of WebGPU in Firefox GPU for the Web

API concepts

WebGPU aims to work on top of modern graphics APIs: Vulkan, D3D12, and Metal. The constructs exposed to the users reflect >the basic primitives of these low-level APIs. Let’s walk through the main constructs of WebGPU and explain them in the context >of WebGL – the only baseline we have today on the Web.

[isafic]

+1 for working with package maintainers. Many linux users avoid things like snap, flatpak, etc. and prefer to keep their system maintainted via their package manager

[jacobleblanc-cs]

Want to express my support for a flatpak package. Distributing that way simplifies packaging work immensely and it's the de facto standard for universal linux packaging.

[Rhelvetican]

Global Suggestion for ZED editor developing including Linux. To make work on plugins parallel to work on editor — VSC was use by millions, not for editor itself. But for easy configuration, command palette and most important plugins (if no external developer then Microsoft write is by self — work on plugins was parallel). Plugins for various language and use case — so get some developer of plugins' attentions soon as possible and make a bunch of it to start. Many users and developers, drop ATOM because of lack of certain plugins to work.

I don't see how this is related to the Linux port?

[storopoli]

make all VSC working in ZED

Oh god, please NO! I don't want the bloat of VS Code. I want a helix GUI.

One nice thing would be to integrate with Devcontainers so that immutable distro users can easily use it with podman/docker containers in a flatpak.

[storopoli]

make all VSC plugins working in ZED

Oh god, please NO! I don't want the bloat of VS Code. I want a helix GUI.

Why? Plugins (specific plugins) are, must have or the ZED end like ATOM.

Yes, but not the bloated ones in "YavaScript" that VS Code has... Or maybe, you can do YavaScript but it needs to be able to compile down to WASM?

[M-Reimer]

That's all not relevant to the Linux port. There are people here watching this Issue to get notified about updates on the availability on Linux. They now get constantly notified with all this off topic stuff.

[anirban6996]

I am really excited for the linux port, I wish I could help somehow but I am really a beginner, I know nothing about GPUI and I am just learning Rust, Also I am unable to find any discord server regarding Zed to connect with the community. I wonder who will be the maintainer of Zed in AUR. It's nice seeing all this rapid progress in a Linux port, best wishes from my side.

[alerque]

@anirban6996 That is pretty off topic for this thread. It's kind of a moot point until Linux is actually supported but please comment on AUR related issues on the zed-editor package or submit contributions via PR here. It won't be long-lived in the AUR though, there is enough interest that I'll be moving it to official Arch Linux repos just as as soon as there is a stable release that works half way decently an no blockers regarding dependencies or whatever.

[flukejones]

Blade seems like a poor choice when compared to wgpu, particularly in regards to being widely tested and used. So far I've been unable to run the latest zed state, or the blade examples - https://github.com/kvark/blade/issues/75

[aminya]

Blade seems like a poor choice when compared to wgpu, particularly in regards to being widely tested and used. So far I've been unable to run the latest zed state, or the blade examples - kvark/blade#75

The current state is still in development, and there is still much work to do (e.g. #7664, #7555, etc.)

Most of the code contributed so far has been by volunteers. Nothing stops others to contribute a wgpu implementation.

The implementation is partially reusable for other libraries (shaders, interfaces, text systems, etc.). Given the current Blade work, adding wgpu implementation is easier.

[mikayla-maki]

Blade seems like a poor choice when compared to wgpu

wgpu requires some CPU overhead to provide features we don’t need. If we choose to switch off of blade, it’ll be to wgpu-hal or Vulkan directly. These kinds of long term technical commitments are not up for debate but we appreciate folks trying to help out :)

[julianbraha]

wgpu does not provide the access to some features we currently use

@mikayla-maki could you share more details on what these missing features are? I was considering using wgpu for something, and would like to know what you guys encountered.

[almoatamed]

i cant wait!!!!!!

[Titaniumtown]

please stop spamming this issue, people (like me) are subscribed to this issue and get notifications on every comment.

[iSaluki]

Regarding packaging, if a Fedora package is desired I can help produce or coordinate this as a member of Fedora packaging. Please do contact me if you'd like help with that.

[Titaniumtown]

Wanted to note progress on input handling (only on x11 so far) is being made with #7811

[teohhanhui]

Wanted to note progress on input handling (only on x11 so far) is being made with https://github.com/zed-industries/zed/pull/7811

Which is why discussion on this issue is important. Many have already indicated that it's a waste of time and effort to support the legacy X11, but unfortunately it seems like the community's input is falling on deaf ears...

[jansol]

@teohhanhui On the contrary: that that PR is written by someone from the community rather than Zed staff, so I'd say the community's input is being very much put to good use. (Although I personally do agree on Wayland being the more interesting target. Alas I don't currently have much time to help advance that implementation so I'll just have to wait for someone else to do so.)

If you have objections to the approach taken in some PR, voicing them in the comments of said PR would seem more useful than here. This is a progress tracking issue after all, not an RFC.

[Titaniumtown]

file dialogs: #7852

[Titaniumtown]

Wanted to note progress on input handling (only on x11 so far) is being made with #7811

... and here's wayland! #7857

[ckissane]

Is there any reason most of the discussion seems to be about using gtk as a toolkit instead of QT?

Additionally, I don't think it makes sense to do client-side decorations just because one DE (gnome), says they like them. For most other DEs, like KDE Plasma and xfce, this is not the norm.

At the very least If one does add support for some sort of fancy client side decorations, It should be an option in my opinion.

[MrHaroldA]

Additionally, I don't think it makes sense to do client-side decorations just because one DE (gnome), says they like them. For most other DEs, like KDE Plasma and xfce, this is not the norm.

I thought Xfce switched to CSD as well? https://www.omgubuntu.co.uk/2020/01/xfce-4-16-client-side-decoration

[Jak2k]

Additionally, I don't think it makes sense to do client-side decorations just because one DE (gnome), says they like them.

But what, when that one DE is used by most distros?

[phisch]

This discussion seems a bit pointless, considering you have to implement client side decorations for gnome anyway. You can then make this configurable, for example how vscode gives you the option between native, and custom decorations, where native means the compositor draws their own decorations, and custom means vscode draws client side decorations.

[Titaniumtown]

Wayland fractional scaling: #7961 Wayland improved keyboard handling: #7970

[jansol]

This discussion seems a bit pointless, considering you have to implement client side decorations for gnome anyway.

Not to mention that Zed already chooses to unconditionally do CSD on macOS, as a style choice. For GPUI in general it's a more open-ended question, but I think that warrants opening a separate issue just for sorting that part out.

[ryuukk]

Additionally, I don't think it makes sense to do client-side decorations just because one DE (gnome), says they like them. For most other DEs, like KDE Plasma and xfce, this is not the norm.

I thought Xfce switched to CSD as well? https://www.omgubuntu.co.uk/2020/01/xfce-4-16-client-side-decoration

They made it optional after backlash from users https://gitlab.xfce.org/xfce/libxfce4ui/-/issues/14

Making it optional is the only valid answer, gnome is not "linux", next up is smartphone UI, because using the mouse is "too precise", everyone is typing code on a touchscreen, so buttons should be huge icons instead, oh wait

too late..

[ryuukk]

To people complaining, brace yourselves https://linuxiac.com/gnome-background-apps/

Enshitification of linux

Signed: redhat and microsoft

[KGrewal1]

Regarding fsevents becoming cross platform, for linux there are inotify bindings for rust (https://docs.rs/inotify/latest/inotify/), however there seems to be a bit of wrangling needed to get this to work with the current framework eg the file flags coming directly from ffi: is this something that you'd prefer to have done in-house at zed due to how opinionated this may be?

[Fullbrik]

To people complaining, brace yourselves https://linuxiac.com/gnome-background-apps/

Enshitification of linux

Signed: redhat and microsoft

What does this have to do with zed. I'm glad you don't like gnome (you are entitled to your opinion), but spreading fud isn't helping anyone. Zed can have client and server decorations. The wayland spec even allows you to query the desktop of server side support without worrying about gnome vs kde vs sway vs whatever. Linux is getting better and I've been dying for something like zed to come around for a while now, and seeing the progress on it so far is amazing.

[SomeoneToIgnore]

I think we've got enough off-topic comments at this point, locking the entire conversation to avoid spamming peoples' emails. @\mikayla-maki or anybody else relevant to the actual development process are welcome to undo this, or (as I would prefer but not insisting) post development updates here themselves.

Consider opening a PR with related changes or using Zed Discord as a platform for discussions.

[SomeoneToIgnore]

Small update: the web site is being transitioned gradually towards multiple platforms: https://zed.dev/download

and seems that Linux build is quite usable at this point, so we hope to have "alpha" Linux builds will soon be published regularly.