GPUI2 and extensions

[coderedart]

As GPUI2 is still in progress, i was wondering if zed people actually looked into how they will support plugins?

I was just reading https://zed.dev/blog/zed-weekly-27 , and it seems like you are using rust features like traits and closures for the new GPUI2 api, whichhich is good while you are working with rust, but are generally not easily scriptable/bindable vscode has the advantage of using electron (browser) and simply makes everything a simple json object or delegates more complex stuff into a electron's webview . This allows plugins to be very powerful.

I did not find any clear plan regarding extensions yet. But considering that you are rewriting GPUI anyway, might as well consider scriptability in your new design before its locked down further. Otherwise, extensions will need a new custom UI framework, or GPUI2 will need to be rewritten again in the future to support extensions.

[stjepangolemac]

Why would they need to rewrite GPUI2 to support extensions? If it's a framework (which I believe to be true) they'd just need to use it to build extra UI around extensions.

I also want to add something to the plugin system discussion and that is considering an approach that is perhaps a bit uncommon.

• Every plugin is started up as a separate (child?) process
• Communication is done through standard pipes
• Messaging format could be something simple like a stream of JSON messages
• Zed starts up all plugins on startup and communicates the current state
• A thread continuously reads all messages and lets the rest of the system know
• This is simple to architect for an MVP
• This could also be wildly extensible (supporting a more efficient binary communication format, multiplexing streams so that plugins can send messages while streaming a video into the Zed UI)
• This is probably very easy to scale as plugin communication can be divided over N threads

[coderedart]

Why would they need to rewrite GPUI2 to support extensions

Not to support extensions. But to let extensions create their own UI. vscode can just reuse electron's webview , but zed will have to provide a custom solution.

As you can't use rust to script, you will need to embed something like mlua or rquickjs with bindings to GPUI2 (really hard with the current trait/closure based api.). or embed wasmtime with bindings which is even harder as you need to go full "C FFI" mode for this (even harder to do it in a safe way).

To given proper examples:

1. gtk vs qt: gtk is C based, which allows everyone to bind to it easily. this is why we have multiple rust crates binding to gtk. OTOH qt is based on cpp semantics like classes/inheritance, which makes it really hard to bind to. Despite qt's popularity, there's no decent bindings in rust yet. If GPUI uses too many rust features like traits/closures, it will also be hard to bind to.
2. egui vs imgui: imgui providing a c api allows many languages (py, js, rust etc..) to embed it. But despite attempts, very few bindings can be written for egui which is very similar to GPUI in its usage of closures/traits.

Anyway, i only raised this issue because GPUI is currently in the middle of a rewrite. So, there might still be a chance to consider extension's UI needs. or just deal with it (by probably rewriting it partially atleast) when they start thinking about extensions

[stjepangolemac]

To be honest I don't know anything about the planned extension system. I just know that they've had a few attempts that ended up in the bin. Therefore, I might be completely wrong on these things.

Do they even need to allow extensions to display custom UI? Things like these might be more than enough to communicate intent and state between the editor and its extensions:

• Expose custom commands in the Cmd+Shift+P menu
• Allow extensions to decorate code in the same form as LSPs do (underlines, hover information, gutter highlights, etc)
• Expose the API for extensions to show an icon in the bottom right corner that can change color or state in some way
• If you really need to allow extensions to show some UI maybe it could be done in a highly controlled manner such as the extension providing a JSON schema that defines the UI, and periodically updating the UI state in the form of JSON messages through the pipes.

[coderedart]

Do they even need to allow extensions to display custom UI?

If they don't, then its fine :) This issue is not a demand, but rather a reminder.

But considering that you are rewriting GPUI anyway, might as well consider scriptability in your new design before its locked down further.

[Alaz-Oz]

Do they even need to allow extensions to display custom UI?

I think yes, why not?

At least I want that in my editor, or what else will support these:

• Show all TODO comment lines from all the project files in a single place. (Needs some kind of UI)
• Show git commit tree.
• Preview for different types for files, eg: svg could be previewed, android-xml to visuals, dot graph to visuals, etc.

[JosephTLyons]

Thanks for reaching out. We want to better support our community, and the best way for us to do that is through our official Discord. The team is active there and happy to help.

We’re closing the “Help and General Q&A” category on GitHub Discussions and directing all support questions to Discord going forward.

https://zed.dev/community-links