Discussion

[alphastrata]

So, what are we envisaging for this? @kmgill

Do we have a list of the first 'things/functionality' from mars-raw-utils that we want to see in here?

If we have a few sketches on what the proof of concept looks like I'm happy to take a stab, as I mentioned the other day I use egui at my dayjob from time to time, so can probably throw something up relatively quickly.

[kmgill]

For the initial version, I envision the ability to browse and download the remote images. Doesn't need to be fancy, just enough to identify wanted images and tag them for download. Once down, or even in the process, the calibration window would be based for the most part on the RawTherapee UI, but limited to the functionality that MRU supplies as a most people do post processing in Photoshop, GIMP, etc, anyway so no need (yet) to reinvent the wheel.

As much as I'd like Qt or GTK, I see egui as pretty easily supporting this and a lot more lightweight and easier to support across platforms. That's not from too much experience as I've as of yet done no GUI development with Rust.

Quick and dirty brainstorming design:

[alphastrata]

Ok, couple of thoughts:

• This submodule stuff has got to go -- I suggest we use a workspace (the rust way), this is basically a mono repo where all your apps/libraries etc exist as their own crate (directory) there's a master Cargo.toml at the top which binds them all together.
  This gives us .tomls that look like:

This workflow is EXTREMELY nice to work with, as all serde deps (for example) will be the same version across all of our crates, it has added benefits for compilation speeds etc too (potentially because you build one version of serde, instead of 5...etc ). My favorite thing about it is just that you can bump things so easily, and know it's bumped across all crates.

• The mars-raw-utils-data should, as it's required by mars-raw-utils just be in there, if you don't want it to be part of it's repo we could make a custom build.rs which could download them etc as part of the crate's build process. However, GUI apps would be expecting to find this sort of thing locally as an asset anyway....
• Are we thinking that all the buttons/sliders in the GUI are just forming the String that makes up a comand to pass to the mars-raw-utils CLI and we just call it for everything? or, are we thinking that we use it as a library an the GUI spools up workers to carry out that work?

If the workspace idea seems repulsive, we can directly path to git deps in our Cargo.toml(s), which would be this sorta thing:

[dependencies]
dependency_name = { git = "git_url" }

We could then, in mars-raw-utils for example use a build.rs like this:

fn main() {
    // Set the destination directory for cloning
    let repo_url = "https://github.com/MarsRaw/mars-raw-utils-data.git";
    let dst_dir = "mars-raw-utils-data";

    if !std::path::Path::new(&dst_dir).exists() {
        // Clone the mars-raw-utils-data repository
        match git2::Repository::clone(repo_url, &dst_dir) {
            Ok(_) => println!("Successfully cloned repository"),
            Err(e) => panic!("Failed to clone repository: {}", e),
        }
    } else {
        println!("Destination directory already exists. Skipping clone operation.");
    };
}

Which would clone the repo prior to the magic that cargo build does, as build.rs scripts are run prior to the stuff in src.

---

WIP thusfar:

I haven't had much time to look into the initial-wip yet, here's an initial sketch, that is compiling:

Basically working towards this:

(made with https://excalidraw.com/)