8000 relm4::app::RelmApp::run_async catches cli args which causes panic · Issue #667 · Relm4/Relm4 · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

relm4::app::RelmApp::run_async catches cli args which causes panic #667

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
Gigas002 opened this issue Aug 3, 2024 · 3 comments
Open

relm4::app::RelmApp::run_async catches cli args which causes panic #667

Gigas002 opened this issue Aug 3, 2024 · 3 comments

Comments

@Gigas002
Copy link
Gigas002 commented Aug 3, 2024

As title says, the relm4::app::RelmApp::run_async function catches the arguments, I pass to my application.
I've migrated my app from relm4 version 0.5 to 0.9, and noticed that change in behavior.

While I was running the app like this, and everything worked perfectly well:

fn main() {
    let args = Args::parse();
    // Keep the guard alive till the end of the function, since logging depends on this.
    let _guard = init_logging(&args.log_level);

    let app = relm4::RelmApp::new(APP_ID);
    app.run_async::<Greeter>(GreeterInit {
        config_path: args.config,
        css_path: args.style,
        demo: args.demo,
    });
}

After migration, this code still works... sometimes. However, after addition of --demo argument to application, it's been noted, that app fails to run with error:

Unknown option --demo

Even though clap read args correctly.

It seems like the call to gio::application::ApplicationExtManual::run in a relm4::app::RelmApp::run_async function forces the attempt to parse the arguments:

    fn run(&self) -> ExitCode {
        self.run_with_args(&std::env::args().collect::<Vec<_>>())
    }

which fails, since gio doesn't know about my app's arguments, but parses them, gets some demo and kills itself.

In relm4's 0.5 version, the relm4::app::RelmApp::run_async function just called gio's run_with_args function, and it didn't trigger arguments search, which worked perfectly well.

So, for now, as a dirty hack, I'm starting my application by initializing the empty args vector:

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

But it doesn't seem to me like a right thing to do
@Gigas002 Gigas002 mentioned this issue Aug 3, 2024
Merged
@Gigas002 Gigas002 changed the title relm4::app::RelmApp::run_async catches cli args relm4::app::RelmApp::run_async catches cli args which causes panic Aug 3, 2024
@max-ishere
Copy link

As a fellow Relm user, this is really annoying.

@AaronErhardt
Copy link
Member

Sorry for responding so late, I somehow missed the notification.

So, for now, as a dirty hack, I'm starting my application by initializing the empty args vector

This has been the recommended approach. Relm4 hasn't tried to change the default behavior of gio in this case, so that's how things work currently.

That said, it makes more sense to me to make this more explicit. If you just build an app, add clap and parse CLI options, you should not run into problems by default. So I propose the following API:

  1. If you don't do anything special, gio won't receive any CLI args (so no "dirty hack" is necessary anymore).
  2. If you want to pass specific args to gio, it's going to be the same as it is now.
  3. If you want to pass all args to gio (which is currently the default), you can use a with_default_args() method in the app builder.

@max-ishere
Copy link

That's how it used to be and I think this is the best approach.

rharish101 added a commit to Gigas002/ReGreet that referenced this issue Dec 22, 2024
@rharish101
Add workaround for CLI arg parsing
ef718ac 
See: Relm4/Relm4#667
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@AaronErhardt @Gigas002 @max-ishere
0