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.

Goal: Linux Nightly build

• Add Client Side Decorations for:
  • resizing
  • moving
• Fix scrolling
• Decide how to distribute the binary
• Remove blade fork
• Fix modifiers getting stuck on
• Fix seg fault on exit
• Fix the cursor sometimes not changing
• Render a menu / improve GPUI prompts
• Support XDG trash
• Resolve all todo(linux)
• Remove non-functional mic and screenshare UI

Goal: Linux Preview build

• Add support for the primary selection buffer
• Add fallback/error if certain portals aren't installed
• Add support for LiveKit's rust SDK and our media integrations
• Integrate with gsettings and equivalent to get settings
• Add support for File drag and drop
  • Initial implementation
  • Fix conflicting data device usages between Drag and Drop and smithay-clipboard on GNOME
• Go through issues and fix them
• Check performance
• Implement the CLI
• Implement IME
• Distribution

Goal: Full Linux Release

• Identify Zed staff who want to use Linux long term
• Fix anything that comes up from public testing on preview
• Hook up crash reporting, telemetry, etc.
• Finalize distribution

[jgcodes2020]

Priority is to make a 'native feeling' window, if we can do that with X11 and Wayland directly, like winit does, then we should do that.

Window decorations on Linux are a mess.

1. All X11 window managers will provide decorations for you.
2. Some Wayland environments can provide decorations for you via xdg-decoration. This includes KDE, plus Sway and other wlroots-based compositors.
3. Other Wayland environments (read: GNOME) want you to draw your own decorations. GNOME developers are adamantly against server-side decoration. I can't tell if Zed currently uses client-side decoration, but if not, that is a high priority. See this GNOME blog post for their guidelines.

EDIT: Just read the task list again. GTK 4 will not let you create a simple window with a fullscreen Vulkan context as you might want.

[JamesMowery]

+1 to please officially support both Flatpak and AppImage formats.

[julianbraha]

Rust SDK is cross platform, but it uses tokio, which we don't want to use.

@mikayla-maki could you expand on this? I've had a good experience with tokio and am unaware of the downsides.

[ringods]

You might want to look at the reasoning of @mitchellh for not providing Linux binary builds, but working with package maintainers:

https://x.com/mitchellh/status/1750942357510627605?s=20

[mikayla-maki]

@julianbraha we provide our own executor that integrates with the macOS runtime and would prefer to not be running multiple independent executors if we can help it.

Tokio is awesome and I love the project, it’s just not in our particular niche :)

[julianbraha]

we provide our own executor that integrates with the macOS runtime and would prefer to not be running multiple independent executors if we can help it.

I see, so it would be easier to port this executor to other platforms, than to replace Zed's executor with Tokio?

[mikayla-maki]

Exactly!

[Akselmo]

Flatpak is good for something you want on multiple linux distros with least amount of effort. However remember that flatpak has some security systems in place, so for example reading header files from /usr/... can be difficult for language-server processes that are launched within the flatpak. (This may be changed over time, dunno)

Having a tarball that distro packages can just make installable (or people can just drop it in ~/.local/bin/ is probably the best at first.

Look and feel wise, i hope you go for a solution that works on most platforms: KDE Plasma uses QT, GNOME uses GTK and so on. GTK is likely the most flexible across multiple desktop environments (or bare WM's), because Plasma can "modify" GTK themes to fit in (albeit it's never really perfect fit).

Decorations, and well everything-else wise: Just use xdg portals. They're the bread and butter of modern linux desktop. :)

Edit: To add, avoid targeting X11. It is on it's way out of many desktop environments. Wayland is the preferred target.

[aminya]

I made three pull requests to get the ball rolling.

#6854
#6855
#6859

The next step is to implement a Wgpu or Vulkano backend.
I started the work here, however, Gpui assumes an interface that is hard to implement for things other than MacOS Metal, and it takes quite a lot of time and expertise in GPU to do that. So it needs to be teamwork.

I have seen the Windows implementation here, but not sure if it is sustainable to duplicate the work for each operating system instead of using a cross-platform abstraction.
https://github.com/PianoPrinter/gpui_win

Originally posted by @aminya in https://github.com/zed-industries/zed/issues/6868#issuecomment-1913485159

[flukejones]

You might want to look at the reasoning of @mitchellh for not providing Linux binary builds, but working with package maintainers:

https://x.com/mitchellh/status/1750942357510627605?s=20

Both can be done. It's not unusual for projects based in rust to provide static builds and many folks who come to the github project will not care so long as they can download it. On the same note, I've seen more than a few projects keep a table of known distro builds that others contribute, plus it's not unlikely to see distros pick up a popular editor.

And lastly - flatpak is certainly another option (and distribute through flathub.org). Between static builds plus flatpak it pretty much covers all bases.

[kvark]

@aminya
For completeness, I'd also like to point out the following possible approaches (in addition to wgpu and Vulkano):

1. Blade-graphics. Gives you portable Metal/Vulkan/GLES/WebGL with little to no overhead. Notably, a very easy porting path from Metal, e.g. resource handles can be copied around and stored freely.
2. wgpu-hal. Gives you portable Metal/Vulkan/D3D12/GL/GLES/WebGL/WebGPU backend with little to no overhead. Plus side - being well tested as it sits below wgpu. On the minus side it's a bit verbose and requires some care.
3. ash. Just a raw Vulkan API, so would sit alongside the existing Metal backend instead of replacing it (I don't expect you to be interested in MoltenVK). Very verbose and quite difficult to program for.

I've been working on the Blade port of GPUI in here - https://github.com/kvark/zed/tree/blade. It should be able to replace the existing Metal backend of GPUI once we see promise on Linux/Windows.

[aminya]

@julianbraha we provide our own executor that integrates with the macOS runtime and would prefer to not be running multiple independent executors if we can help it.

Tokio is awesome and I love the project, it’s just not in our particular niche :)

@mikayla-maki Could you elaborate on your criteria for evaluating a runtime?

I think the approach should be to write cross-platform code with maximum maintainability rather than reinventing all the wheels. That would just delay shipping features, and it would make it harder to maintain and develop later. In the open-source community, it is important to work together and reuse where possible

[WeetHet]

@mikayla-maki, as far as I see, live kit only provides client side sdk for rust and not the server side one. Is the plan to write the server side SDK ourselves?

[mrnugget]

@mikayla-maki, as far as I see, live kit only provides client side sdk for rust and not the server side one. Is the plan to write the server side SDK ourselves?

The server (see our collab crate) is already running on Linux machines, as far as I know.

[theArianit]

snap would be fine too, since it is better for accessing the terminal (out of the box, without any configuration) than flatpak.

[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.

[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 :)

[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

[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.

[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?

[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.