zed
zed copied to clipboard
zed-industries
Linux Roadmap
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
- [x] moving
- [x] Fix scrolling
- [x] Decide how to distribute the binary
- [x] Remove blade fork
- [x] Fix modifiers getting stuck on
- [x] Fix seg fault on exit
- [x] 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
- [x] 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
- [x] Initial implementation
- [ ] Fix conflicting data device usages between Drag and Drop and
smithay-clipboardon GNOME
- [ ] Go through issues and fix them
- [ ] Check performance
- [ ] Implement the CLI
- [x] Implement IME
- [x] 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
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.
- All X11 window managers will provide decorations for you.
- Some Wayland environments can provide decorations for you via xdg-decoration. This includes KDE, plus Sway and other wlroots-based compositors.
- 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.
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.
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
@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 :)
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?
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.
I made three pull requests to get the ball rolling.
https://github.com/zed-industries/zed/pull/6854 https://github.com/zed-industries/zed/pull/6855 https://github.com/zed-industries/zed/pull/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
Priority is to make a 'native feeling' window, if we can do that with X11 and Wayland directly
Please don't expend effort on X11, it is very very much on the way out the door and some distros, and many desktops are now forcing wayland only.
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.
@aminya For completeness, I'd also like to point out the following possible approaches (in addition to wgpu and Vulkano):
- 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.
- 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.
- 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.
@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
@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?
@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.
snap would be fine too, since it is better for accessing the terminal (out of the box, without any configuration) than flatpak.
Please don't waste time on X11. In the last couple years there has been a complete sea change and X11 development (from the X server side) is completely dead. All new development is being done on the Wayland side, all distros have been switching to it by default, it is the only way to support new hardware, etc. X11 stuff will hang around for a long time but for a big new project to do a bunch of coding specific for it would be a bad investment of time. Architect for Wayland and move on. If the community backports to X11 from there that's fine, but trying to architect for it out of the box will hold things back significantly.
Please don't waste time on X11. In the last couple years there has been a complete sea change and X11 development (from the X server side) is completely dead. All new development is being done on the Wayland side, all distros have been switching to it by default, it is the only way to support new hardware, etc. X11 stuff will hang around for a long time but for a big new project to do a bunch of coding specific for it would be a bad investment of time. Architect for Wayland and move on. If the community backports to X11 from there that's fine, but trying to architect for it out of the box will hold things back significantly.
While this is true, a lot of accessibility features are not available under Wayland, so many people use X11 still, and those should not be disregarded
While this is true, a lot of accessibility features are not available under Wayland
This was much more true a year or two ago, it has come a long ways. It is not 100% on par yet, but 100% of the display server developer momentum is behind Wayland. X11 is abandoned even by it's own former core developers. While some existing apps may have a case for not ditching support quite yet if holding onto existing support isn't costing them much, but I do not believe many new apps have much of a case to make for developing for something that is a known dead end. In Zed's case in particular working on a custom UI toolkit it would be a poor choice to design it around a legacy system that does not support new hardware, stopped getting bug fixes years ago, and distros are actively trying to deprecate (in some cases successfully).
that does not support new hardware
Which new hardware are you talking about?
that does not support new hardware
Which new hardware are you talking about?
Graphics for one. While there will be a general level of usability for now, you should expect it to get worse over time as things advance well past what X11 is capable of. X11 has many issues, not least of which is poor multi-display support (on hybrid laptops especially, and in general).
2024 will see a lot of momentum behind wayland. To try supporting X11 at this time is poor time and effort investment.
snap would be fine too, since it is better for accessing the terminal (out of the box, without any configuration) than flatpak.
Except that it is supported only by canonical and locked down by them. There is pretty much zero chance of use outside of ubuntu.
Graphics for one
Which, exactly? Could you name some models? Wayland has a lot of issues with all of the NVIDIA GPUs, so most GPUs on the market. You cited some unnamed “new graphics hardware” without any details.
@GoldsteinE I see that you are heavily invested in xorg with your nix setup (and bspwm - nice tiler tbh, I used to use it) so this is going to be my only response to you as I'm wary of emotional investment in such things. I understand you are likely anxious due to talk about not supporting xorg while you still use it.
Asus send me ROG laptops to support under linux every year, The general trend I've seen is the nvida based external outputs are very poorly supported in xorg. This drastically reduces usability, meanwhile KDE-6 which is shifting to wayland only handles nvidia-outputs with different resolutions and scaling very smoothly - no issues at all so far in my testing. The step up in quality and usability over the old xorg session is incredible (oh and you get better touch/gesture support). The same can be said of the coming Cosmic desktop suite. And Budgie is moiving to wayland only, so is Gnome. XFCE is working on it. Cinnamon is.... The 2 major desktops plus a large smattering of others.
So poor display handling. Poor performance in some instances. And the general momentum. Xorg is an evolutionary deadend that is no-longer supported.
At this point, a Wayland backend should be the target for any new software, and an x11 backend a best effort by whoever wants to contribute it. Ubuntu is switching to wayland by default, Fedora has been for a while now and Mint already have an experimental Cinnamon Wayland session. The majority of GPUs out there I'd dare say are integrated graphics, not nvidia, especially on non-gaming setups and laptops. The Nvidia situation is far better today than it was a year ago.
Oh god. X11 terminators flooded here. Please don't flood productive projects with your rants. X11 and Wayland are both >> actively used << software, with no vanishing in sight for many years at this time. There is zero point in discussing it or advocating for such things here.
For an application developer, it should be an abstracted detail. I would definitely suggest using (/re-shaping) a library that abstracts this detail, and provides you a nice start, eg. a window with a Vulkan drawing context, on any OS, on any stack, or on any GPU.
~~Linux~~ Non-MacOS Support
By using slightly nice abstractions, and by avoiding Linux specifics from day 1, OS support could be expanded well beyond Linux. BSD or other OS users could benefit as well.
Input Method
On the other hand, there are a few problems that all new software experiences if the UI stack is a scratch one. Input Method support is the first in the list. I think winit now has it partially covered. Details could be seen here for reference => https://github.com/rust-windowing/winit/issues/1497 It is a complete deal-breaker, when users cannot input non-latin/CJK into an editor.
Not sure how suitable SDL would be as a dependency, for dealing with low level graphics setup, AFAIK, it also provides good level of abstraction, yet allows the app to do the rendering. SDL's platform support is no-joke. Overhead, I don't know but probably less than GTK4.
Packaging and Distribution
This is where the community could be most helpful, and it would not effect specific details of the application design much I guess? Although, packaging sometimes means sandboxing as well. (next item)
Sandboxing and portals
Supporting for xdg portals from the beginning would be very healthy. Firefox might be a good example there, it's file open/save dialogs work with portals if portal support is found on session bus, otherwise it attempts native access to the files/folders. Thus it works with both sandboxed and non-sandboxed cases. For Zed editor, I believe it would be relevant for opening/saving files and folders, and for clipboard access.
Accessing global git configuration or git/ssh/gpg credentials might be tricky in sandbox situations. Not accessing credentials is even better, probably by leveraging ssh-agent/gpg-agent and such.
If this other needs for credentials, keychain/wallet~ish subsystems are not standardized yet afaik. or org.freedesktop.portal.Secret is there for it? it might need checking. As an example, I see that Chromium making it a CLI argument to enable, https://wiki.archlinux.org/title/KDE_Wallet#KDE_Wallet_for_Chrome_and_Chromium
Other related projects, also working on cross platform support;
- lapce - uses custom UI lib, over wgpu
- alacritty - uses winit & glutin
- sublime text - non-foss, uses gtk4 afaik, suffers from input method issues on some setups
Except that it is supported only by canonical and locked down by them. There is pretty much zero chance of use outside of ubuntu.
well, you can install snaps on other distros too, like for example all big distros
This is a tracking issue for our plan for Linux support.
Let’s not get into a debate about X11 vs Wayland here. If you’d like to discuss the merits/downsides of them, please open a separate GitHub discussion.
Same goes for packaging approaches. If you have opinions on the matter, please open a discussion.
I suggest contacting the warp.dev to perhaps discuss the solution they use to achieve the same thing. The experience has always been great on macOS and Linux with Warp, and this is also a Rust project with (IIRC) a custom renderer.
