Proof of concept egui integration.

[follower]

[TODO: Add some context. ]

[hannobraun]

Thank you, @follower, this is awesome!

Do you think we can start merging this soon? I haven't properly reviewed this yet, but the changes look really reasonable. And the GUI itself looks great. A bit overloaded maybe, with all the egui debug stuff, but a great base to build upon.

I think the main problem might be, that this is based on a pretty old (~2 months) version of the main branch. I don't think the graphics code itself has changed much since then, but it has moved into another crate (fj-viewer), and everything winit-related has been extracted from that recently (into fj-window). So this will require some shuffling around, before it can be merged.

[follower]

*sigh* (That's an existential sigh, not one directed at you...)

TL;DR: Yeah, I was aware of it being an outdated version, but as the computer I'm using is not ever likely to be mistaken for "what peak performance looks like", I wanted to avoid a re-compilation stage of unknown duration in order to update at that point.

Anyway, I had an updated (to May 26th) almost working version about a month ago but ran into a couple of issues & life.

But tonight I managed to fix/workaround the issues and got egui @ v0.18.0ish and main as of c85c096 working/hacked together:

And, yeah, that specific UI was mostly included for pedagogical reasons.

Architectural question

Also, while I have something working I also realised that in order to know how to proceed it would be good to clarify the architecture you're wanting because currently the "integration" of egui with the existing fj-app/viewer is somewhat "reinventing the wheel" when we could use eframe instead & just worry about the application UX & geometry functionality.

Essentially the three options are:

• An "integration" of egui into fj-app so fj-app is the base of it all & egui is essentially only UI.
• Use the eframe framework to handle I/O etc but still only layer the GUI over a window that fj-app controls/draws.
• Lean fully into the egui world & just have Fornjot render onto a graphics layer when egui provides one in a callback.

Assuming you still want to continue down this road, what would be your preference?

[hannobraun]

Anyway, I had an updated (to May 26th) almost working version about a month ago but ran into a couple of issues & life.

But tonight I managed to fix/workaround the issues and got egui @ v0.18.0ish and main as of c85c096 working/hacked together:

That's great, @follower! Thank you for your continued work on this!

There haven't been many changes to fj-window/fj-viewer lately, so c85c096 should be plenty current. I expect minimal to no changes going from there to main.

Could you push your latest branch? I'd love to take a look and get it merged as soon as possible.

Also, while I have something working I also realised that in order to know how to proceed it would be good to clarify the architecture you're wanting because currently the "integration" of egui with the existing fj-app/viewer is somewhat "reinventing the wheel" when we could use eframe instead & just worry about the application UX & geometry functionality.

At this point, I have no problem with reinventing the wheel. You have a working egui integration, so let's get that merged quickly, so it doesn't get out of date again. Whether it's using the right architecture or not, I'm sure it's a better basis for further iteration than not having any egui integration at all.

Essentially the three options are:

• An "integration" of egui into fj-app so fj-app is the base of it all & egui is essentially only UI.
• Use the eframe framework to handle I/O etc but still only layer the GUI over a window that fj-app controls/draws.
• Lean fully into the egui world & just have Fornjot render onto a graphics layer when egui provides one in a callback.

Assuming you still want to continue down this road, what would be your preference?

I have no idea what the best long-term solution is, but right now option 1 seems like the lowest risk to me (with the caveat that it shouldn't get integrated into fj-app, but fj-viewer/fj-window; but that probably was just a typo).

Since I have no experience with either egui or eframe, I can't judge whether it's a good idea to bind ourselves more closely to it. It might turn out well, but it sounds to me like getting married at your first date. Since the "reinvent the wheel" implementation is what you already have, we should just merge that and use it to gather experiences. We'll be in a better position to make a less temporary decision some time down the line.

There are also other considerations, like I'd like to replace our custom rendering code with an external library, if that is practical (#657). I don't know how that will affect our options.

[follower]

Closing in favour: of #763