Zed as Flatpak! (Runs on Wayland natively)

[ShobuPrime]

Hello everyone! I'm happy to share my build for Zed as a Flatpak for Linux!

https://github.com/ShobuPrime/flathub/tree/dev.zed.Zed

It will be merged to Flathub soon given the proper approvals. Please let me know what you think!

[arslivinski]

It would be nice if this Flatpak was verified by being an official Zed release instead of a user package. Couldn't we add this to the official repository?

[ShobuPrime]

finished the flathub submission process

That's exactly why I created the topic here for feedback while I sort out the issues the Flathub maintainers notice according to their standards.

Prior to this, I've only released one other Flatpak for Enpass

Apparently one of the challenges of building and releasing this Flatpak (since it's compiled with cargo) is that it needs to be performed entirely offline from within the build steps and we rely on the flatpak-builder to aggregate and cache the dependencies. The current commit ATOW was built with the following build args:

      build-args:
        - --share=network
        - --filesystem=home

Which (while working if you clone and install manually) are not up to Flathub's standards.

A good example of a Rust application I personally use with Flatpak is Mission Center -- so now I'm learning how to make sure my next commit in the PR can build offline just like their manifest does.

When and if the Zed developers want to take over maintenance of the flatpak on flathub, they will easily be able to do so.

That is certainly the goal -- I don't plan to be the sole owner of the repo once it's submitted, but I also wanted to help offer a solution/option to use Zed other than only compiling from source.

[clseibold]

@ShobuPrime Right. I certainly appreciate the work you put into making the Flatpak. Flathub seems to be pretty restrictive on some things, and the sandbox is a bit more complicated to deal with while also adhering to Flathub's standards, so I think there's more work being done in the Flatpak v3 issue.

[someone13574]

Yeah, @ShobuPrime feel free to suggest/review anything in the v3 PR or to work on anything in the todo list. Its now at a point where there are zero sandbox related issue and will never have any sandbox issues because it simply exits the sandbox. It also has offline building.

[clseibold]

@ShobuPrime Btw, I think for offline stuff, @someone13574 uses cargo-flatpak-generator to generate a flatpak manifest that pulls in all of the cargo dependencies - I think that's how that works at least.

[someone13574]

Yes, the script generates a file that contains url's for the tar.gz of each dependency. This then allows flatpak to download the deps at the correct time instead of during the build process where flathub doesn't allow you to for reproducible builds and security reasons.

[someone13574]

This will have a ton of things broken due to spawning processes in the sandbox. This includes language servers and the terminal as the major ones.

[ShobuPrime]

I view this a simply an option, no different than how other code editors like VSCode exist -- and certainly don't expect it to be the primary installation method.

Flatpak has language specific SDKs which can be included in the manifest to have languages natively work within the Flatpak, such as Golang

I expect you can also use the host shell just like the VSCode Flatpak allows you to do. I've been using it just fine with no issues for Golang development.

On machines like the Steam Deck, where natively it doesn't allow you to edit the OS -- having an Zed packaged as a Flatpak is very beneficial -- even if it's just for text editing. In this example, not every Steam Deck owner is going to disable the RO-Filesystem.

[ShobuPrime]

If you give the Flatpak permissions to the D-Bus Session Bus

you can use your host shell as such:

I expect you can probably change your default Zed settings to always use the host shell if you're concerned about Sandbox

[someone13574]

A better way is to run the main app outside of the sandbox. See here: #12006

[ShobuPrime]

I'm happy to share I've refactored the Flatpak thanks to the official Zed package being released -- and consequently the manifest is now much simpler rather than having to deal with offline cargo builds.

It also accounts for both x86_64 and aarch64 releases, and successfully builds and runs on my machine with my native PATH. For example, Go, Python, Code-OSS are all recognized and executable from a fresh Flatpak build and run from my Arch Linux host.

Build 135681 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/118713/dev.zed.Zed.flatpakref

flathub/flathub#5253 (comment)

[caleb87]

I discovered Zed through this flatpack, but I've never heard of it before. I'm using Zorin OS and just searched the store for code editor and this was first.

I used to use brackets, but it's turned into a nightmare. Brackets can't run large files smoothly (15k lines of code). Zed runs it perfectly and it's simple like brackets used to be. This will be my main code editor now.

Thanks for putting the flatpak together @ShobuPrime

[vikaspoddar]

What is the current status of the takeover of the zed flatpak, where can I find more details

[louiss0]

Thank God this is happening. I like using a CLI to download packages. Zed people please Officially support this.
Flatpack is the most popular way to download packages. Soon it will be the way to do things,

[louiss0]

Hello everyone! I'm happy to share my build for Zed as a Flatpak for Linux!

https://github.com/ShobuPrime/flathub/tree/dev.zed.Zed

It will be merged to Flathub soon given the proper approvals. Please let me know what you think!

How are things going it doesn't seem to be merged? Why?

[someone13574]

It was merged a few months ago: https://flathub.org/apps/dev.zed.Zed

[oddjobz]

Hey guys, I run on Raspberry Pi's and would love to try out Zed. Although it installs Ok via flatpak it reports the GPU is unsupported and warns of performance issues. (and it's quite right, it's too slow for me to use) It "looks" like it should work, vkcube runs happily without any errors, is there a way to make it work as intended on a Raspberry Pi 5?
I've also followed the instructions and built a local copy from source with the cargo instructions, the resulting binary however seems to exhibit the same issue. (this is Raspberry Pi OS, so Debian Bookworm with Mesa 23 native and Mesa 24 in flatpak)

[oddjobz]

Ok, so that works (!) .. is this the way I should use it, or is "flatpak-spawn" an issue? (i.e. is some stuff not going to work for me)
Seems a LOT quicker just doing basic things like resizing the Window.
I've (separately) compiled Mesa 24 from source and installed it .. it's not doing the job, it's showing the old Mesa 23 driver on GPU0 and the new 25 beta on GPU1 .. but still gives the same error when I launch.

[oddjobz]

$ vulkaninfo --summary
WARNING: [Loader Message] Code 0 : terminator_CreateInstance: Failed to CreateInstance in ICD 5.  Skipping ICD.
MESA: error: Use of VkSurfacePresentModeCompatibilityEXT without a VkSurfacePresentModeEXT set. This is an application bug.
MESA: error: Use of VkSurfacePresentModeCompatibilityEXT without a VkSurfacePresentModeEXT set. This is an application bug.
==========
VULKANINFO
==========

Vulkan Instance Version: 1.3.239


Instance Extensions: count = 23
-------------------------------
VK_EXT_acquire_drm_display             : extension revision 1
VK_EXT_acquire_xlib_display            : extension revision 1
VK_EXT_debug_report                    : extension revision 10
VK_EXT_debug_utils                     : extension revision 2
VK_EXT_direct_mode_display             : extension revision 1
VK_EXT_display_surface_counter         : extension revision 1
VK_EXT_headless_surface                : extension revision 1
VK_EXT_surface_maintenance1            : extension revision 1
VK_EXT_swapchain_colorspace            : extension revision 5
VK_KHR_device_group_creation           : extension revision 1
VK_KHR_display                         : extension revision 23
VK_KHR_external_fence_capabilities     : extension revision 1
VK_KHR_external_memory_capabilities    : extension revision 1
VK_KHR_external_semaphore_capabilities : extension revision 1
VK_KHR_get_display_properties2         : extension revision 1
VK_KHR_get_physical_device_properties2 : extension revision 2
VK_KHR_get_surface_capabilities2       : extension revision 1
VK_KHR_portability_enumeration         : extension revision 1
VK_KHR_surface                         : extension revision 25
VK_KHR_surface_protected_capabilities  : extension revision 1
VK_KHR_wayland_surface                 : extension revision 6
VK_KHR_xcb_surface                     : extension revision 6
VK_KHR_xlib_surface                    : extension revision 6

Instance Layers: count = 2
--------------------------
VK_LAYER_MESA_device_select Linux device selection layer 1.3.211  version 1
VK_LAYER_MESA_overlay       Mesa Overlay layer           1.3.211  version 1

Devices:
========
GPU0:
	apiVersion         = 1.2.255
	driverVersion      = 23.2.1
	vendorID           = 0x14e4
	deviceID           = 0x55701c33
	deviceType         = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
	deviceName         = V3D 7.1.7
	driverID           = DRIVER_ID_MESA_V3DV
	driverName         = V3DV Mesa
	driverInfo         = Mesa 23.2.1-1~bpo12+rpt3
	conformanceVersion = 1.3.6.1
	deviceUUID         = 5fd8106e-741a-cafa-e080-fdb16cf11a80
	driverUUID         = 1698c6ef-161f-3213-5159-557202953ee9
GPU1:
	apiVersion         = 1.4.305
	driverVersion      = 0.0.1
	vendorID           = 0x10005
	deviceID           = 0x0000
	deviceType         = PHYSICAL_DEVICE_TYPE_CPU
	deviceName         = llvmpipe (LLVM 15.0.6, 128 bits)
	driverID           = DRIVER_ID_MESA_LLVMPIPE
	driverName         = llvmpipe
	driverInfo         = Mesa 25.0.0-devel (git-e75e9baff8) (LLVM 15.0.6)
	conformanceVersion = 1.3.1.1
	deviceUUID         = 6d657361-3235-2e30-2e30-2d6465766500
	driverUUID         = 6c6c766d-7069-7065-5555-494400000000

[oddjobz]

Ok, answered my own question, the sandboxed version that works complains of "netcat" missing when I try to access a remote machine .. works fine if I use the unsupported GPU incarnation .. albeit extremely slow. I'm guessing if I could make this v24 Mesa work properly it might solve the problem .. but it appears I have a partial native install + a partial new build and I'm not quite sure what to make of that for a second ... kinda looks like it should be working;

$ glxinfo | grep "OpenGL version"
OpenGL version string: 3.1 Mesa 25.0.0-devel (git-e75e9baff8)

[oddjobz]

Hmm. I now have a build of the 24.3 Mesa branch running ... seems to have the same problem. Additionally, running vkcube completely hangs the system :-(

[oddjobz]

... Ok, I now have a version of 24.3 locally compiled .. v3cube and friends are all borked, however zed is now working! If anyone else wants to hobble their system to get it working, I did this;

COMMON_FLAGS="-mcpu=cortex-a76+crc+crypto -O2 -pipe -mtune=cortex-a76" meson setup --wipe --prefix /usr -Dglx=dri -Dplatforms=wayland,x11 -Dllvm=enabled -Dvulkan-drivers=broadcom -Dgallium-drivers=v3d,vc4,llvmpipe -Dglvnd=true -Dbuildtype=release build --libdir=/usr/local/lib/aarch64-linux-gnu
ninja -C build install