Feature flag to use gpui-ce

[dlight]

In the PR zed-industries/zed#42905 (custom shaders), after a Zed developer rejected it they pointed out that upstream development of GPUI is de-emphasizing the needs of GPUI users outside of Zed. Code that isn't directly usable in Zed isn't being merged in upstream GPUI right now.

Other features rejected due to that include Add tray support, Translate Wayland touch events to mouse events and others.

In such cases, Zed developers themselves recommended the use of this fork, GPUI community edition (it has for example a PR for custom shaders), and generally speaking, whenever a feature is rejected due to being out of scope for Zed, people recommend the author should consider submitting it to gpui-ce. (I actually found those threads by doing this search)

Now, it's quite concerning that gpui-ce is 381 commits behind mainline GPUI, I don't see a project like this surviving if they don't pull any and every upstream improvements. Situations like this are somewhat common in open source, (like libav vs ffmpeg, gcc vs egcs etc) and the project that gets most contributions generally win.

But in any case, it would be pretty cool if the users of gpui-component could select at compile time whether they use gpui or gpui-ce, through a feature flag. The feature flag would both control what crate gpui-component actually depends upon, and also, through the use of cfg!() and friends, pepper over any incompatibility that arises. That's similar how many software back in the day had a compile time config to use either ffmpeg or libav.

Anyway, I don't think this situation will last forever. Most of times, either forks end up dying, or, hopefully, being merged back into upstream. Hopefully gpui-ce and gpui will eventually merge - but until them, I think it would be very valuable to have a way to opt into using one or another.

[dlight]

If gpui-component doesn't use any low level graphics API (like calling directly into Vulkan or something like that), eventually it could be valuable to also have a choice to use wgpui. Maybe it makes sense to use wgpui to make GUIs for Bevy games since both use wgpu, idk. But that's not what I am proposing, I just wanted to use gpui-component with gpui-ce.

(Also I just found out there's already a discussion thread about this in #1798.. but maybe an issue is useful anyway)

[ahkohd]

For anyone interested, I've forked gpui and added complete custom draw APIs with both Metal and WGPU backends: ahkohd/ggpui#1

[cosoc]

I think it should be completely independent and should not rely on Zed for iteration. In its current state, the project is basically half-alive.

The public library and the Zed project inherently have conflicting interests. They simply don't want to maintain it as a truly public, general-purpose library. In that case, it would be better to make a clean break and start over by depending directly on CE.

Alternatively, rename the library and create a new project around the underlying core and components. That could give the entire ecosystem a fresh start.

What developers want is a proper, standalone library, not one that has to compromise and bend to Zed's messy dependencies just to preserve GPUI's programming philosophy, while also having to depend on the attitudes and priorities of Zed's developers.

At its core, this is a conflict of interests. The issue isn't that they're not allowed to do it—they simply don't want to.

[huacnlee]

#2234 (comment)

I have replied of this topic.