Upgrade dependencies

[Gigas002]

Mostly minor/non-breaking updates, here's some notables:

• clap: 4.1 -> 4.5. Nothing breaking in between, minor size improvements, 4.4+ requires msrv 1.70+ see: https://github.com/clap-rs/clap/blob/master/CHANGELOG.md
• derivative -> educe. The derivative crate is kinda dead for 3 years alread, as suggested alternative use educe instead. Migration changes are minimal (changing the names of attributes)
• greetd_ipc: 0.9 -> 0.10. Again, nothing breaking here, dependencies upgrades and such: https://git.sr.ht/~kennylevinsen/greetd/log
• gtk4: 0.5 -> 0.9. gdk4::auto::Monitor no longer implements std::fmt::Display; gdk4::auto::Display::open not takes Option<&str> instead of &str; msrv 1.70+; gtk::StyleContext::add_provider_for_display moved into gtk::style_context_add_provider_for_display. More changes in between available here: https://gtk-rs.org/blog/
• lru: 0.9 -> 0.12. Nothing notable, see: https://github.com/jeromefroe/lru-rs/blob/master/CHANGELOG.md
• regex: 0.7 -> 0.10. Minor perf improvements I guess: https://github.com/rust-lang/regex/blob/master/CHANGELOG.md
• relm4: 0.5 -> 0.9. Follwing the gtk4 crate versions. There were some changes in how children templates are searched. The 0.6 version introduced some breakage and a bug, which was fixed in 0.7. Code changes are noticable into the src/gui/component.rs. The migration notes didn't really state these changes, so I had to ask for help for this migration from maintainers into the repo's discussions directly: https://github.com/orgs/Relm4/discussions/659
• tokio: 1.26 -> 1.38. No changes were needed, though the release count in between is pretty big. msrv stays on 1.63 for now. Changes listed here: https://github.com/tokio-rs/tokio/releases
• toml: 0.6 -> 0.8. Minor cleanups/deps stuff, msrv changed to 1.70, see: https://github.com/toml-rs/toml/blob/main/crates/toml/CHANGELOG.md

[rharish101]

I rebased this on the latest main, but unfortunately, clap isn't working with the --demo argument. Specifically, it just outputs the following line:

Unknown option --demo

Using any bogus argument, like --test, returns a well-formatted output:

error: unexpected argument '--test' found

Usage: regreet [OPTIONS]

For more information, try '--help'.

[Gigas002]

Ack, will take a look into it

[Gigas002]

It seems like the clap reading args correctly, but everything fails up here:

// main.rs
app.run_with_args(&args);

When this line is called, args are correct, but something fails further, into dependency. I think it's gio, which is a dependency of gtk, here to blame, since it fails on:

ffi::g_application_run(self.as_ref().to_glib_none().0, argc, argv.to_glib_none().0)

Will investigate/report upstream further

[rharish101]

Is it possible that GTK is also parsing the CLI arguments for itself? That might explain why it crashes, because --demo shouldn't be a default GTK CLI argument.

[Gigas002]

After some thinking, I think it;s relm4 issue actually.

In version 0.5.1, which is in a main branch of ReGreet, the run_async function calls only the app.run_with_args(args); in it's body with empty args in our case. gio's run_with_args function then just continues the execution without attmepts to read args manually.

But in latest version of relm4, the run_async checks if args have been passed, and then runs gio's app.run();, which, under the hood, attempts to read args from command line and fails to recognize demo.

As a dirty hack, we can change the line to execute ReGreet as:

    app.with_args(vec![]).run_async::<Greeter>(GreeterInit {
        config_path: args.config,
        css_path: args.style,
        demo: args.demo,
    });

This works, but...
I'm sure it's to be reported upstream, rather than writing this. Note, that we have to initialize the empty vec here, None won't pass the check and relm4 will try to run args initialization via gio.

[rharish101]

Ah, in that case, let's raise an issue upstream first and see how long they take to fix it and tag a release. If it takes too long, we could just add this hack.

[Gigas002]

Created an issue for this problem, trackable here: Relm4/Relm4#667

[Gigas002]

I think it's kinda safe to introduce a workaround for now. It seems like relm4 is not very active lately, so I doubt they'll fix it soon.
Should I add it? @rharish101