FFI-safe UI and related structures

[kamirr]

Is your feature request related to a problem? Please describe.
Consider a program that wishes to enable development of plugins which could render their own UI within the parent app window. A concrete example would be a Digital Audio Workstation (DAG).

This maps well to egui architecture, as the plugin only needs &mut egui::Ui for most basic functionality. Passing &egui::Context as well would enable more, but isn’t necessary for an MVP.

The issue here is that Rust doesn’t provide a stable ABI out of the box.

Describe the solution you'd like
Make egui::Ui and all arguments of its methods repr(C) and FFI-safe.

Describe alternatives you've considered

1. Switching to a different tech stack — viable, but irrelevant for this discussion
2. Expressing UI in detached FFI-safe data structure and evaluating this within the main app. This works, but the inherent indirection makes the developer UX worse. Also, this doesn’t scale to widgets which the parent app doesn’t explicitly expose.
3. Only share a raw window handle and a rectangle, building another egui instance basing on that. There are some issues like passing the global state of dark/light mode choice or widget styling, but otherwise I think it’s a viable approach as well.

Additional Context
The abi_stable crate could do most of the heavy lifting AFAICT.

Open questions

• Is this feature in line with project goals?
• Support semver-compatible version mismatch, or only the exact same version?
• Performance implications? (I don’t think it’s a real issue, but I have not investigated this)
• Build time implications? If bad, is introducing another feature-flag justified?
• Even if useful, do the users care? If this brings little practical value, additional maintenance cost might not be worth it.

[Burkino]

I've been wondering how I would go about making a plugins feature for a program I'm making.
It would be nice to expand functionality without modifying the actual program.

[coderedart]

maybe duplicate of #1004