3 ms·

>Yup, that's a native file dialog, but we don't use GTK in Zed and that clearly is GTK — so, how does that work? You'll find the answer in the companion video i

>Yup, that's a native file dialog, but we don't use GTK in Zed and that clearly is GTK — so, how does that work? You'll find the answer in the companion video in which Mikayla and I dive deeper into this and also touch on the question of whether or not we should use GTK or Qt or something else (spoiler: it's complicated). Unless I missed it, the video doesn't actually answer the question. They talk 38:50 onwards about how they don't want to pull in GTK / Qt as dependencies, rather they just want to be able to read the toolkits' config and render a mimicking UI themselves. Then they show the editor opening a "native" file dialog, but don't actually say how exactly they did it. Anyway, I assumed they would use xdg-desktop-portal, and based on searching the repo that does seem to be the case.

mikaylamaki 2y ago
Yep! That's how we did it, with the heavy lifting done by the delightfully named "Aperture Science Handheld Portal Device" crate: https://crates.io/crates/ashpd https://crates.io/crates/ashpd
- tomjakubowski 2y ago
  So Zed is using dbus to create and manage the file dialog in a toolkit independent way? Neat
  - Arnavion 2y ago
    Yes, xdg-desktop-portal is a standard dbus interface. The interface covers file picker, print, screenshot, screencast, etc. The implementation of the interface (the "backend") is expected to be provided by the desktop environment in some way that makes sense for that DE. So gnome has xdp-gnome, kde has xdp-kde, etc, and there are some like xdp-gtk that are DE-agnostic but toolkit-specific. Backends can implement a subset of the interfaces, and xdp can be configured to try multiple backends in sequence until it finds one that provides the interface that the application wants. Eg xdp-wlr for wlroots-based Wayland compositors only implements compositor-specific interfaces like screencast, so users would chain it with something like xdp-gtk for other interfaces like file picker. Native applications usually use their toolkits' API for showing file picker dialogs etc, and xdp's file picker interface is primarily used by flatpak applications since that is a way for sandboxed applications to read/write outside their sandbox. But it's not impossible for native applications to also use it, as zed is doing. https://flatpak.github.io/xdg-desktop-portal/docs/api-reference.html https://flatpak.github.io/xdg-desktop-portal/docs/api-refere...
jchw 2y ago
Yeah, there are some caveats to using desktop portals this way, but at least it'll usually give you a native dialog. I do wonder what happens on a machine with no desktop portals, though. I suppose in the future it probably would be feasible to implement a decent file picker directly in GPUI as a fallback, so it's not that big of a deal; I reckon they could make one that's more usable than the GTK one anyways.
zozbot234 2y ago
If you want a GTK-based IDE experience there's always GNOME Builder. Like other modern GTK apps, it actually works quite well with custom GTK themes which provide a Win9x-like look (see the chicago95 and b00merang projects on github) if you want the better usability and higher information density that this enables.
c-hendricks 2y ago
They seem to mention Portals at 10:41 ("Show Transcript", Ctrl+F "portal"): https://youtu.be/O5XVVnA2LoY?t=641 https://youtu.be/O5XVVnA2LoY?t=641

mikaylamaki 2y ago

Yep! That's how we did it, with the heavy lifting done by the delightfully named "Aperture Science Handheld Portal Device" crate: https://crates.io/crates/ashpd https://crates.io/crates/ashpd

tomjakubowski 2y ago
So Zed is using dbus to create and manage the file dialog in a toolkit independent way? Neat
- Arnavion 2y ago
  Yes, xdg-desktop-portal is a standard dbus interface. The interface covers file picker, print, screenshot, screencast, etc. The implementation of the interface (the "backend") is expected to be provided by the desktop environment in some way that makes sense for that DE. So gnome has xdp-gnome, kde has xdp-kde, etc, and there are some like xdp-gtk that are DE-agnostic but toolkit-specific. Backends can implement a subset of the interfaces, and xdp can be configured to try multiple backends in sequence until it finds one that provides the interface that the application wants. Eg xdp-wlr for wlroots-based Wayland compositors only implements compositor-specific interfaces like screencast, so users would chain it with something like xdp-gtk for other interfaces like file picker. Native applications usually use their toolkits' API for showing file picker dialogs etc, and xdp's file picker interface is primarily used by flatpak applications since that is a way for sandboxed applications to read/write outside their sandbox. But it's not impossible for native applications to also use it, as zed is doing. https://flatpak.github.io/xdg-desktop-portal/docs/api-reference.html https://flatpak.github.io/xdg-desktop-portal/docs/api-refere...

jchw 2y ago

Yeah, there are some caveats to using desktop portals this way, but at least it'll usually give you a native dialog. I do wonder what happens on a machine with no desktop portals, though. I suppose in the future it probably would be feasible to implement a decent file picker directly in GPUI as a fallback, so it's not that big of a deal; I reckon they could make one that's more usable than the GTK one anyways.

zozbot234 2y ago

If you want a GTK-based IDE experience there's always GNOME Builder. Like other modern GTK apps, it actually works quite well with custom GTK themes which provide a Win9x-like look (see the chicago95 and b00merang projects on github) if you want the better usability and higher information density that this enables.

c-hendricks 2y ago

They seem to mention Portals at 10:41 ("Show Transcript", Ctrl+F "portal"): https://youtu.be/O5XVVnA2LoY?t=641 https://youtu.be/O5XVVnA2LoY?t=641