Live data from Hacker News

Zed editor switching graphics lib from blade to wgpu

github.com

271–280 of 321 posts

Re: Zed editor switching graphics lib from blade to wgpu

#271
post #247

Earlier quoted context omitted.

In my experience immediate mode guis almost always ignore internationalization and accessibility. The thing you get by using an OS widget and putting a string in it is that the OS can interact with the string. It can read it out load, translate it, fill it in with a password, look it up in a dictionary, edit it right to left, handle input method editors whose hot keys are in conflict with app doing its own editing, e…

Yes, one argument that I didn't make in the post but that does favor immediate mode is that you can somewhat straightforwardly convert from an immediate mode GUI to retained mode by just introducing your own abstractions. In some sense this makes you more disciplined about the FPS which could be a net win over all. [Note that Tritium at least is translated into a number of a different languages. That part isn't that…

hard is this: https://faultlore.com/blah/text-hates-you/

and this: https://lord.io/text-editing-hates-you-too/

those are both things most ImGUIs ignore. And, even if you pick some library that somehow handles the first you're left with all of the issue mentioned above.

To be clear, if I was writing a devtool (and I am actually) i'd reach for an ImGUI (and I did). But I'd be unlikely to use one for user facing tool.

Re: Zed editor switching graphics lib from blade to wgpu

#272

I am confused by this without context. I have not heard of blade, but am aware that Zed built its own GUI library called GPUI. Having used Zed, this is a vote of confidence: The crate ecosystem is historically filled with libaries which try to be The future of X in rust but are disconnected from practical applications. GPUI by nature is not that; it's a UI lib built to a practical and non-trivial purpose. It sounds l…

> as I was looking forward to using GPUI in future applications and comparing it to EGUI. I have asked online in several places for someone to compare who's used both, but I believe this to be a small pool.

I have yet to learn GPUI, but I have used Egui and really like it. I was turned off of GPUI from being forced to have to install Xcode to use it on macOS, which is a major bummer, in my opinion.

Re: Zed editor switching graphics lib from blade to wgpu

#273

I am confused by this without context. I have not heard of blade, but am aware that Zed built its own GUI library called GPUI. Having used Zed, this is a vote of confidence: The crate ecosystem is historically filled with libaries which try to be The future of X in rust but are disconnected from practical applications. GPUI by nature is not that; it's a UI lib built to a practical and non-trivial purpose. It sounds l…

I am one plugin away from moving to it directly instead of vscode. I really like it. It’s fast. It gets updates seemingly daily. I’ve never had it crash. It integrates LLMs well. It’s everything I wish vscode was if it were native.

What is the plugin you are waiting on?

Re: Zed editor switching graphics lib from blade to wgpu

#274

Earlier quoted context omitted.

>What's that, doing actual work rather than labor-of-love open source stuff? except the 'labor-of-love' stuff is what set the editor apart and why real users were choosing it and the 'actual business work' the moneymen are eager about is exactly what's in every other editor and what nobody asked for

They wrote GPUI as a business decision, to focus on performance, because they knew that that would be a core differentiator to all the other IDEs out there that use Electron for example. That they also liked writing it (as a "labor of love") is incidental.

Didn't they also invent Electron for their Atom editor when working at GitHub? Which then was hijacked by Microsoft and VS Code. Was Electron (Atom Shell) a core differentiator of Atom? Absolutely. Was it a business decision? No, it was a dream to use javascript/html/css to build a desktop editor. I think, similarly, Zed was an experiment to build a modern desktop app without any C++ legacy or OS API wrappers.

Re: Zed editor switching graphics lib from blade to wgpu

#275

Earlier quoted context omitted.

> We gotta focus on some business relevant work in 2026 Remember that post announcing the millions of VC capital they raised? This is the result

You vastly overestimate the amount of pressure a board can place on an early stage startup. The far more likely scenario to me (someone who raised VC money) is that the CEO likely looked at their run rate and decided to prioritize things more aggressively. This is hardly surprising and it has nothing to do with VCs.

Doesn't it have something to do with VCs? Does the company behind Zed actually make any money on their own?

Re: Zed editor switching graphics lib from blade to wgpu

#276
post #231

Earlier quoted context omitted.

Not if you dynamically link it. LGPL.

Is it that simple?

Happy 10 years to the GPL & LPGLv2.1->LGPLv3 license update & Qt starting to expose more of Qt. https://lwn.net/Articles/671755/

Re: Zed editor switching graphics lib from blade to wgpu

#277

Earlier quoted context omitted.

https://zed.dev/releases/stable#:~:text=Improved%20editor%20... Fixed last october

Tried it when it when that update released and just now, still blurry as ever.

Do you have a screenshot? I just tried Zed out on Linux and biggest issue was that it assumed an rgb subpixel layout.

- https://pasteboard.co/ZDnQm80dHANx.png

- Top is wezterm which is correct.

- Bottom is Zed which uses rgb.

- Both are using Inconsolata though wezterm claims size is 16 and Zed is at 18. I don't have any screen scaling.

*edit formatting

Re: Zed editor switching graphics lib from blade to wgpu

#278
post #30
post #4

Rust GUI is in a tough spot right now with critical dependencies under-staffed and lots of projects half implemented. I think the advent of LLMs has been timed perfectly to set the ecosystem back for a few more years. I wrote about it, and how it affected our development yesterday: https://tritium.legal/blog/desktop

I'd love to read a writeup of the state of Rust GUI and the ecosystem if you could point me at one.

https://www.reddit.com/r/rust/comments/1pl9lz0/comment/nty3c...

Re: Zed editor switching graphics lib from blade to wgpu

#279
post #82
post #4

Rust GUI is in a tough spot right now with critical dependencies under-staffed and lots of projects half implemented. I think the advent of LLMs has been timed perfectly to set the ecosystem back for a few more years. I wrote about it, and how it affected our development yesterday: https://tritium.legal/blog/desktop

Honestly I think all native GUI is in a tough spot right now. The desktop market has matured so there aren't any large companies willing to put a ton of money into new fully featured GUI libraries. What corporate investment we do see into new technologies (Electron, SwiftUI, React Native) is mainly to allow developers to reuse work from other platforms like web and mobile in order to cut costs on desktop development.…

I believe it's never been a better time for cross-platform desktop GUI. Vulkan API works on Windows, Android, Linux. Even web has Vulkan support. The only outlier is Apple.

On Linux, Wayland provides better drawing surface and input API.

The only missing piece is a high-level GUI and Vulkan/Metal compatibility layer. Along with ancient issue of packaging of course.

Re: Zed editor switching graphics lib from blade to wgpu

#280
post #274

Earlier quoted context omitted.

They wrote GPUI as a business decision, to focus on performance, because they knew that that would be a core differentiator to all the other IDEs out there that use Electron for example. That they also liked writing it (as a "labor of love") is incidental.

Didn't they also invent Electron for their Atom editor when working at GitHub? Which then was hijacked by Microsoft and VS Code. Was Electron (Atom Shell) a core differentiator of Atom? Absolutely. Was it a business decision? No, it was a dream to use javascript/html/css to build a desktop editor. I think, similarly, Zed was an experiment to build a modern desktop app without any C++ legacy or OS API wrappers.

Those creators own their company in the case of Zed, so it is a business decision. Otherwise they could've just gone with Electron again. The business decision is that they wanted to be different in the market, the speed of vim with the IDE capability of VSCode.
Post reply on HN