Evaluate options for auxiliary GUI on desktop platforms

[hannobraun]

To make Fornjot more user-friendly, it is desirable to have GUI elements that integrate with the local environment, like an "open file" dialog to select a model to load before Fornjot is started. Such a solution would likely be platform-specific (desktop platforms would likely require something else than mobile platforms or the web) and not be closely integrated with core Fornjot functionality (closely integrated GUI is tracked in #116).

I haven't done this kind of GUI development in Rust yet, and don't know a whole lot about the available options. Ideally, we'd have something that is easy to use, solid, works the same on Linux/Windows/Mac (at least), and doesn't require too much from the user (to install many native libraries, for example).

The objective of this issue is to choose existing options to evaluate, choose a suitable use case to evaluate them with (see below) and implementing that use case. If an evaluation is positive, it can be merged.

Labeling as https://github.com/hannobraun/Fornjot/labels/good%20first%20issue, as this issue doesn't require much familiarity with Fornjot. Labeling as https://github.com/hannobraun/Fornjot/labels/help%20wanted, as I have no experience in this field, and advice is much appreciated.

This issue is a more specific follow-up to #4.

Thoughts on use case

I think a suitable use case would be the following: If Fornjot is started without any command-line arguments that define which model to load, open a "load file" dialog (or some other kind of suitable "start screen") to allow the user to choose a model. Once a model is chosen, start Fornjot proper (i.e. the model view that is currently the only GUI).

We could decide to integrate that GUI more closely (for example by having a menu that allows opening other models during runtime), but that can come later.

See related issue: #58

[follower]

I noticed the Lapce editor (developed in Rust) recently changed to using native file dialogs following user request(s), so thought I'd mention that as a potentially useful data point.

In their case they switched to using tinyfiledialogs which I subsequently discovered is actually a wrapper around a C library.

Additional file dialog crate options

Via the related lib.rs pages[1][2] (which I find more useful than crates.io for discovering/comparing crate options) I noted the following alternate options also exist & stood out:

• rfd a.k.a. "Rusty File Dialog"
  • Mentions WASM32 support.
• native-dialog
  • Can be enhanced via im-native-dialog which adds Immediate Mode GUI support & includes an egui example.

I haven't personally used any of these options but hopefully these crate pointers might serve as a helpful starting point for the evaluation process. :)

[hannobraun]

Thank you, @follower!

Looks like very useful information. Since I have little experience with this topic (as stated above), posts with these kinds of research notes are very useful, and very welcome!

[hannobraun]

I have decided to close this issue, for the following reasons:

• The example use case I talked about has been implemented, using one of @follower's suggestions (Rusty File Dialogs).
• On desktop platforms, it's unclear to me what we even need beyond that, as egui and RFD seem to work well. I'm sure that new requirements will reveal themselves in the future, but until then, there's nothing to base an evaluation of further options on.
• On the web, it's pretty clear to me that HTML elements/forms are the best way to control an embedded Fornjot widget (as opposed to, say, some canvas-based egui UI).

So, in summary, everything that was actionable here has been done, and it's unclear what else we need beyond that.