What is the accessibility story with Zed? I have a vague memory that atom had none of it.
Linux When?
51–60 of 169 posts
Re: Linux When?
#52>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 abou…
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
So Zed is using dbus to create and manage the file dialog in a toolkit independent way? Neat
Re: Linux When?
#53Earlier quoted context omitted.
Or… use one of the existing cross platform toolkits that have existed for decades. Text Editors, traditionally, did not require shaders to run or be performant, and not require entire systems worth of RAM.
Out of curiosity, how many of them run at 120 FPS? (honest question - I've never looked into it myself)
This is the first time I see FPS mentioned for a text editor. Is this something that matters or just an pointless metric utilized as selling point?
Re: Linux When?
#54Earlier quoted context omitted.
Or… use one of the existing cross platform toolkits that have existed for decades. Text Editors, traditionally, did not require shaders to run or be performant, and not require entire systems worth of RAM.
Out of curiosity, how many of them run at 120 FPS? (honest question - I've never looked into it myself)
The question doesn’t make sense. They don’t rerender the buffer every frame. I assume zed isn’t doing that either as it would be horribly inefficient.
I presume what is meant is that it can handle a redraw fast enough to be in the next frame. In which case the answer is: all of them. Drawing text is not the bottleneck for a GUI program, unless you have a god awful browser stack as your rendering engine.
Re: Linux When?
#55Atom, like most recent editors like VS Code etc., are just clones of Sublime Text with just lots of bloat and JavaScript tech. I'll just stick to Sublime Text.
You're aware that Atom is not the subject of the article, right?
I believe some of the Zed folks invented Atom back in the day. But yes, it doesn't seem like a highly relevant comment...
Re: Linux When?
#56Earlier quoted context omitted.
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
So Zed is using dbus to create and manage the file dialog in a toolkit independent way? Neat
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-refere...
Re: Linux When?
#57Earlier quoted context omitted.
Out of curiosity, how many of them run at 120 FPS? (honest question - I've never looked into it myself)
This is the first time I see FPS mentioned for a text editor. Is this something that matters or just an pointless metric utilized as selling point?
Well it may have effect on ergonomics. Some people claim they cannot use 60Hz monitor after trying 144hz.
Re: Linux When?
#58I'm curious why Zed chose Blade over wgpu/wgpu-hal. There's a bit of detail here: https://github.com/zed-industries/zed/issues/7015 But I'd be curious to read a longer writeup on the tradeoffs and how they came to their decision.
Partially because Kvark, who has a long history in graphics programming, was enthusiastic about it, and has similar values of simplicity and effectiveness to our own. Mainly because our renderer is simple enough that we would have preferred to use Vulkan APIs directly, rather than going through wgpu. Blade is a thinner abstraction than wgpu, it's a bit more ergonomic than wgpu-hal, and it already supports our long te…
wgpu (and webgpu more generally) is often presented as a very good choice for a cross platform low level graphics api. but it was designed around safety/security constraints to support the web, sometimes at the cost of performance (my understanding)
i heard somewhere this nice example: only big actors like AAA game engines would really benefit from the extra development effort it would take to use an even lower level api like vulkan/dx12 to squeeze the last 10% of performance that wgpu can't get you
so if i understand correctly, zed, just like a AAA game engine, wants to squeeze every last bit of performance from the gpu, and so wgpu is "too high level" for it? and blade is "like wgpu, but no design tradeoffs and lower level" so its a better fit? does that mean someday zed might reach for vulkan directly one day? im assuming dx12 is gonna be used on windows anyway?
i love kvark's work btw, we need more kvarks
Re: Linux When?
#59I tried it out briefly, and it seems promising so far! Zed reminds me a lot of Lite [1] and its community successor Lite-XL [2], which are also "built like a videogame" using a custom renderer and ui engine. [1] https://github.com/rxi/lite [2] https://github.com/lite-xl/lite-xl
>"built like a videogame"
A term coined Casey Muratori for this is immediate-mode GUIs or else IMGUI programming[1]. Hence the name for the very popular Dear ImGui project. GPUI used for Zed is mentioned as hybrid immediate and retained mode UI framework[2].
[1]: https://caseymuratori.com/blog_0001 (fist post on his blog!) [2]: https://github.com/zed-industries/zed/tree/main/crates/gpui
Re: Linux When?
#60Still baffled by the idea of make a code editor not only single OS but targeting mac.