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.
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.