Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zed editor switching graphics lib from blade to wgpu

github.com

Post reply on HN
Print view View original

281–290 of 321 posts

Re: Zed editor switching graphics lib from blade to wgpu

#281

Post by tensor »

jenadine wrote: post #219
tensor wrote: post #192

Earlier quoted context omitted.

Iced seems really promising, however, it's a passion project by a single developer. They very clearly stated that their goal is to follow their passions and desires first, everyone else second, and that it will always be a single person project. Their readme even discourages contributions. Companies using it in production are often forking it as a result, and trying to keep their fork in sync. Ultimately, if the comm…

Isn't System76 supporting and contributing to iced?

Yes, but they maintain their own fork and are good about syncing. It's still not an ideal model long term.

Re: Zed editor switching graphics lib from blade to wgpu

#282

Post by jason_oster »

socalgal2 wrote: post #271
piker wrote: post #247

Earlier quoted context omitted.

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.

Those are also things that most retained mode GUIs ignore, unless they are "platform native". Only a small number of GUI implementations get these things right because they are hard. There are many, many GUI implementations, and most of them are pretty rough, to put it mildly.

It has nothing to do with how the state is managed. (This is the only distinction between immediate and retained modes.)

Re: Zed editor switching graphics lib from blade to wgpu

#283

Post by actualwill »

bmitc wrote: post #273
gigatexal wrote: post #95

Earlier quoted context omitted.

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?

Not OP but I can’t leave jet brains until a double shift search everywhere is implemented.

Re: Zed editor switching graphics lib from blade to wgpu

#284

Post by KingOfCoders »

ffreire wrote: post #125
KingOfCoders wrote: post #111

Switched from Intellij (various) to Cursor because of AI integration, only using Claude Code CLI, switched to VS because Cursor became so annoying every release, pushing their agents down my throat, activating what I did deactivate every release, recently thought "Why do I even use that slow bloated thing of VS?" and switched to Zed. Very happy camper. So much faster. So much snappier. Would love Claude Code CLI inte…

Are you familiar with ACP[0]? Through that protocol you can run claude code within zed[1]. Or perhaps I'm not understanding what you mean by using CC integration. [0]: https://agentcommunicationprotocol.dev/introduction/welcome [1]: https://zed.dev/docs/ai/external-agents#claude-code

ACP is so much worse than Claude Code CLI - the quality is not there. Everyone assumes the JSON-CLI-API is the same as the CLI but it is not. Tool usage is different, and I assume agent system prompts are different and agents are different.

Integration like in Cursors, I use the CLI and Claude Code knows what files are open, uses Cursor for diffs etc.

Re: Zed editor switching graphics lib from blade to wgpu

#285

Post by jakkos »

the__alchemist wrote: post #93

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…

> It sounds like Blade is a cross-API graphics engine, by one of the original gfx-HAL (former QGPU name) creators?

My understanding is that wgpu has a lot of constraints and complexity imposed on it by all the backends it has to support (especially WebGPU) and that Blade is meant to be a much simpler closer-to-metal api for people who want more control (and know how to not shoot themselves in the foot)

> I would be using eframe instead of WGPU as the backend.

Do you mean using egui-wgpu directly rather than through eframe? The default backend of eframe is wgpu (it used to be glow/opengl), and you can still use callbacks to directly render whatever you want with wgpu in an eframe app

> EGUI and WGPU have great integration

Can confirm, it was stupid simple to integrate egui into my wgpu gamedev project

> Am I missing something about Zed? I have tried and failed to get into it.

I also tried Zed after getting annoyed at Helix a few times, and thought "oh cool, this is like vscode but fast and even has a helix mode!" but then didn't find any killer features worth abandoning the synergies of having an all-in-terminal-workflow over

Re: Zed editor switching graphics lib from blade to wgpu

#286

Post by pjmlp »

SigmundA wrote: post #227
pjmlp wrote: post #195

Earlier quoted context omitted.

No, that is event based programming, and also the basis of retained rendering, because you already have the controls that you compose, or subclass. Handling WM_PAINT is no different from something like OnPaint() on a base class. This was actually one of mindset shifts when moving from MS-DOS into Windows graphics programming.

Event based or loop based is separate from retained or immediate. The canvas api in the browser is immediate mode driven by events such as requestAnimationFrame If you do not draw in WM_PAINT it will not redraw any state on its own within your control. GDI is most certainly an immediate mode API and if you have been around long enough for DOS you would remember how to use WM_PAINT to write a game loop renderer before…

I even remember WinG, Win32s and co.

You are forgeting most folks did not use bare bones C with WM_PAINT and nothing else.

Most sane devs were quick to adopt C++, even Petzold books moved into C++ still during Windows 3.1 days, although the code samples stayed pretty much the C subset common to both languages, see the preface on his book.

As such many games had their own retained frameworks built on top of Win32 controls, wrapped into C++ classes, or if they were casual games, they would build upon OWL, VCL (Borland TP, C++, Delphi), MFC (VC++), VB.

The kind of games where you would get a bootload of shovelware CDs when buying a Media PC with MS-DOS/Windows 3.1.

Re: Zed editor switching graphics lib from blade to wgpu

#287

Post by piker »

socalgal2 wrote: post #271
piker wrote: post #247

Earlier quoted context omitted.

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.

Tritium is a rich text editor. I'm familiar with the issues outlined in those posts.

To be fair with a lot of the GUI frameworks in various ecosystems ... they try to solve different pieces of them.

Re: Zed editor switching graphics lib from blade to wgpu

#288

Post by Matl »

bmitc wrote: post #272
the__alchemist wrote: post #93

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.

Iced.rs is also neat[0].

0 - https://github.com/iced-rs/iced

Re: Zed editor switching graphics lib from blade to wgpu

#289

Post by Matl »

pjmlp wrote: post #21
piker wrote: 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

Interesting read, however as someone from the same age group as Casey Muratori, this does not make much sense. > The "immediate mode" GUI was conceived by Casey Muratori in a talk over 20 years ago. Maybe he might have made it known to people not old enough to have lived through the old days, however this is how we used to program GUIs in 8 and 16 bit home computers, and has always been a thing in game consoles.

It makes perfect sense if you consider his ego.

Re: Zed editor switching graphics lib from blade to wgpu

#290

Post by outcoldman »

qznc wrote: post #173
the__alchemist wrote: post #93

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…

Zed competes mostly against Visual Studio Code. Not against Jetbrains.

Maybe, but I switched from IntelliJ to Zed. And eventually stopped paying for Jetbrains products.
Post reply on HN