[POC] Refresh on (extracted) parameter update via UI.

[follower]

[TODO: Add some context]

[hannobraun]

Oh, nice! Those screenshots look great, @follower!

I'm busy getting the new release out right now. I'll take a closer look once I'm done (and after I've merged #763).

[hannobraun]

Okay, the new release is out, #763 is out, and I'm ready for this PR!

First off, I made an attempt to rebase this branch on top of latest main. The release, merging #763 (or rather, the changes I made to merge it) and some unrelated changes to fj-viewer caused conflicts. Here's the result: https://github.com/hannobraun/Fornjot/compare/main...wip/egui

I didn't pay a lot of attention to correctness. My main goal was to get something quickly that I can test. Therefore, I don't know if the following problems I noticed where there in the first place, or if my rebase introduced them.

First off, it doesn't look the same for me, as it does in the screenshots:

The UI on the left is no longer displayed correctly.

And this is what happens when I try out the spacer model:

$ cargo run -- -m spacer
    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
     Running `target/debug/fj-app -m spacer`
found `fj::model` function: model
    found arg with value attribute: "outer"
    found arg with value attribute: "inner"
    found arg with value attribute: "height"
   Compiling spacer v0.1.0 (/home/hanno/Projects/main/fornjot/models/spacer)
    Finished dev [unoptimized + debuginfo] target(s) in 0.34s
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: ParseFloatError { kind: Empty }', models/spacer/src/lib.rs:3:1
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Other than that, there are a few minor issues, but this is a proof-of-concept, so no reason to nitpick.

I'm running out of time for today, so I probably won't be doing much more here for now. I still need to check out how you get the parameters and their default values from the model, or look at the code in any kind of depth.

[hannobraun]

Okay, I've now had a chance to look at this more closely, and check out how it works.

I think from a UI perspective, this is a perfect starting point! However, the approach used to load the default parameters from the model is the wrong one, in my opinion. If I understand correctly, it parses the source file of the model. This duplicates the parsing code that already exists in fj-proc, and ties the implementation to Rust as a modeling language, making it more difficult to add support for other languages via WASM (#71) or other means.

Now that we have #[fj::model], we can handle parameters in a more robust way: By having #[fj::model] generate an API in the model that the host can query to learn which parameters exist, and what their values are. I would accept pull requests that take the code base in that direction, but I'd also like to note that I think it makes more sense to address #71 first, as any infrastructure between host and model would need to be updated anyway when making the switch to WASM.

All of this shouldn't be seen as a complaint about your work, @follower! The pull request is clearly marked as draft, and has "proof of concept" right in the title, so I certainly didn't expect you to address long-standing architectural issues. I just want to put this pull request into a wider context, and address how this work could go forward, in my opinion.

What do you think, @follower? Where do you see this pull request going from here?

[hannobraun]

I've opened an issue with thoughts on what a host API that could properly support this functionality could look like: https://github.com/hannobraun/Fornjot/issues/804

[hannobraun]

I've kept this pull request open, as I hoped that it could serve as a template for future work along those lines. However, due to the recent changes (see A New Direction), this feature is no longer in scope. Closing.

Thanks again for your work, @follower!