Repository navigation
Linux Roadmap #7015
Description
Activity
- pinned this issue
on Jan 29, 2024 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.
Reacted by Titaniumtown, Luke Simmons, adrian5, bbb651 🇮🇱, Andrew Ares, Dot32, Eas, awsms, Gen, Ole Jørgen Brønner and 24 moreReacted by Melroy van den BergReacted by brunoais and Reverier Xu+1 to please officially support both Flatpak and AppImage formats.
Reacted by Moises Hidalgo, jgcodes2020, Julian Braha, Luke Simmons, Taylor, Dot32, zengsheng, xpdmk, Sean, entropicdrifter and 88 moreReacted by Ghalib Ansari, Falk Pauser and John McBrideRust 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.
Reacted by Titaniumtown, Felix Zeller, Luke Simmons, Dot32, Foodornt, Bruno Ochotorena, Yashwanth Reddy Gondi, Suraj, Amanullah Menjli and AgustínYou might want to look at the reasoning of @mitchellh for not providing Linux binary builds, but working with package maintainers:
Reacted by Felix Zeller, Locke Bircher, Wyatt Childers, Amolith, awsms, William Desportes, Foodornt, Suraj, Michael Harding, garrison hinson-hasty and 2 moreReacted by Zeno Jiricek and AnshuReacted by Sean, Eonfge, Suraj, Kaan Büyükerdem and Paul ShryockReacted by Amolith, Nathan Anderson and Suraj@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 :)
Reacted by Antar, kaigedong, Suraj, Jacob LeBlanc, Mikel Solabarrieta and Marshall Pauleywe 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?
Reacted by Abdelkarim Ben HamidaExactly!
Reacted by Luke Simmons, Michael McMahon, Dot32, lena, Sean, Abdelkarim Ben Hamida, Suraj, Gabriel Dantas, Jacob LeBlanc, Ghalib Ansari and 3 moreFlatpak 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
xdgportals. 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.
Reacted by Stanislav, Sean, Marc-André Lureau, Andrea Giammarchi, brunoais, Nirfse, Dave Patrick, ShugarSkull, SpineEyE, w3irdrobot and 34 moreI made three pull requests to get the ball rolling.
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_winOriginally posted by @aminya in https://github.com/zed-industries/zed/issues/6868#issuecomment-1913485159
Reacted by Zander, Felipe Raimann, kaigedong, Marc-André Lureau, github user, Philipp Sander, Furkan Mustafa, basings, Free 公園, Abdelkarim Ben Hamida and 11 moreReacted by kaigedong, David, Furkan Mustafa, Foodornt, Chance Snow, Elias Carvalho, Leonardo Razovic, Julius, Mikel Solabarrieta and Forrest Hopkins63 remaining items
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.
Reacted by Amin Ya, xpdmk and Luke SimmonsReacted by Luca SelinskiAdditionally, 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
Reacted by Luca SelinskiAdditionally, 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?
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, andcustomdecorations, wherenativemeans the compositor draws their own decorations, andcustommeans vscode draws client side decorations.Reacted by Shell, Lyna, Austaras, Rom Grk, Mateusz Mikuła, daigennki, Robert Barabas, Roman, Ilia, Jeffrey Mudge and 37 more- Reacted by Rajas Paranjpe, Caleb Maclennan, aparatext, Paul, mhanuszh, Whoman, Dat Ngo Quoc, TerminallyDied, Roman Solomatin, Tomas Sandven and 13 moreReacted by Furkan Mustafa, Roman Solomatin, Sam, Samy Lahfa, Gus and Teoh Han HuiReacted by Philipp Schaffrath, Shell, xpdmk, Leonardo Razovic, jansol, Jun Ouyang, Tommy Johnston, yodatak, Teoh Han Hui and Tiago José ValdrichReacted by nandgator, Daniele B, Tomas Sandven, Alix, Samy Lahfa, Lucas Moraes, Jun Ouyang, Teoh Han Hui and Tiago José ValdrichReacted by Philipp Schaffrath and Jun Ouyang
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.
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?
- locked as off topic and limited conversation to collaborators
on Feb 18, 2024 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.
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.
- unpinned this issue
on Jul 10, 2024
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 containingtodo(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