Hi, I am trying to use klask, but during compilation, I am receiving an error:

Compiling klask v0.3.0
error[E0599]: the method `to_string` exists for reference `&ArgValue<'_>`, but its trait bounds were not satisfied
  --> /home/opoopo/.cargo/registry/src/github.com-1ecc6299db9ec823/klask-0.3.0/src/arg_state.rs:54:28
   |
54 |                 .map(|s| s.to_string())
   |                            ^^^^^^^^^ method cannot be called on `&ArgValue<'_>` due to unsatisfied trait bounds
   | 
  ::: /home/opoopo/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-3.0.0-beta.5/src/build/arg/arg_value.rs:28:1
   |
28 | pub struct ArgValue<'help> {
   | --------------------------
   | |
   | doesn't satisfy `ArgValue<'_>: ToString`
   | doesn't satisfy `ArgValue<'_>: std::fmt::Display`
   |
   = note: the following trait bounds were not satisfied:
           `ArgValue<'_>: std::fmt::Display`
           which is required by `ArgValue<'_>: ToString`
           `&ArgValue<'_>: std::fmt::Display`
           which is required by `&ArgValue<'_>: ToString`

For more information about this error, try `rustc --explain E0599`.
error: could not compile `klask` due to previous error
warning: build failed, waiting for other jobs to finish...
error: build failed

my cargo.toml contains:

[dependencies]
clap = {version = "3.0.0-beta.4"}
klask = "0.3.0"

I was able to resolve the problem with adding to the clap source files in the arg_values.rs file:

impl<'help> ToString for &ArgValue<'help> {
    fn to_string(&self) -> String {
        return self.name.to_string();
}

Thank you for reaply

Hi, we're making a simple fractal renderer and at some point wanted to try klask. It's brilliant :D I tried implementing a progress bar by calling klask::output::progress_bar with my approximate progress. It compiles, but when I run, I get panic in this line: https://github.com/MichalGniadek/klask/blob/c6b1544b5c1dd25a7c950a0969e569ecfae5f926/src/output.rs#L181 The text in the iterator doesn't seem to be the expected text in the Some arm, instead it's sth. like Some("124568479524573"). I was able to reproduce this a number of times. Later trying to reproduce it while filing this issue, I wasn't able to reproduce it anymore :/ Instead, I got this: After which the application freezes. I'll post the repo link as soon as we switch it to public if you are interested.

Thanks again for the work you've put into Klask.

I think that we should replace the environment variable KLASK_CHILD_APP by a --gui / --cli flag. This would allow to have only one binary for both graphical and command line interfaces.

Cheers

Thanks for your hard work on this crate. It's extremely quick to use.

I wonder if it's possible to show the cli arg in other language, say, in Chinese, in the gui, since the user of my small app does not know English. A simple example would be, the app has an arg 'file_path', and I want it displayed as '文件路径' to the user, which means exactly 'file_path' in Chinese.

Thanks in advance for your help.

Proof-of-concept fix for #51, using an unsafe static mut CTX to save the egui::Context.

Doing this right could be done by adding a ctx field to the Klask type, however, this may be a big conceptual change? Also, egui::Context does not impl std::fmt::Debug, so it breaks the #[derive(Debug)] on Klask.

Let me know what you think when you have the time :)

When I make tools using Python's Gooey library, I usually end up wanting a CLI version for myself (and maybe other power-users) and then a GUI for everyone else in the office.

If it's possible to get both a CLI & GUI binary from the same source code, it would be helpful to have an example.

Is this easily possible with conditional compilation or some other method?

Hi,

The file chooser currently hangs on Mac OS. This is probably downstream from https://github.com/balthild/native-dialog-rs/issues/23

Happily, it looks like they've fixed that, or at least made progress on it, as of version 0.6.2 — so upgrading the dependency version is hopefully all that's needed.

I don't know how hard this would be, but it would be useful to me if the area in the main window where stdout is displayed also supported entering text into stdin. Specifically, I klask-ified a program which was using rustyline, a readline-like crate. Of course this gets into the realm of terminal emulators (?) so might be quite challenging, but anyway here goes the suggestion, feel free to close if not in scope.

The child process is being called with the clap app name as the first arg. I printed env::args() when the process starts so you can see that.

At quick glance, I see the app name is added to the arg list in Klask::execute (here) which didn't seem right. As a quick test, it appeared to work for me if I replaced that line and kill the subsequent validation check:

    fn execute(&mut self) -> Result<ChildApp, ExecuteError> {
        // let args = self.state.get_cmd_args(vec![self.app.get_name().into()])?;
        let args = self.state.get_cmd_args(vec![])?;

        // Check for validation errors - disabled since the validation expects the app name arg
        // self.app.clone().try_get_matches_from(args.iter())?;

But even though that works for me, I feel like I'm missing something since it seems like there is an intention to use the app name argument to distinguish some "outer" subcommand, but I didn't completely grok how that works (why wouldn't run_app always start the GUI and just put the logic on the calling code to decide when to call run_app?

Some cansi functions will be marked as deprecated with cansi v3.

See here: https://docs.rs/cansi/latest/cansi/v3/index.html

Let me know what you think :)

Thanks for this awesome library :wink:. This pull request updates eframe and other dependencies to their latest version.

It ignores clap and uuid as those are already updated in this pull request. Note that I also created a pull request for that pull request which solves the unicode problem and that you may merge directly.

Hey, this pull request updates eframe and fixes compilation on wasm32.

It also publishes the internal modules app_state and settings, so that this app can be embedded into another egui app. Take a look at this demo of using klask to update configuration at runtime (top-left buttons) to see why this is useful.

Sadly, this last contribution increases the size of the public API, and you may not want to maintain a bigger API. If this is the case, I'll maintain the fork for my projects.

Hi :)

I noticed that currently, if a multiple_values field has a default value, this value does not appear initially in the list of arguments (which initially is empty). But when clicking the "Reset to default" button, the default value is entered as the first entry in the multiple_values sequence.

This change pre-populates the multiple_values vector with the default value, if one is given. On "Reset to default", this state is restored. The default value can also still be edited and removed with the - button.

Let me know what you think :)

I just discovered there is a minimal case where klask crashes with a not-so-helpful error message:

use clap::Parser;
use klask::Settings;
use std::{thread, time::Duration};

#[derive(Debug, Parser)]
struct Args {
    verbose: bool,
}

fn main() {
    klask::run_derived::<Args, _>(Settings::default(), |args| {
        dbg!(args);
    });
}

It's arg_state.rs:280, trying to get the name of the bool, which isn't available as it is not annotated with #[clap(short, long)]. I suppose this makes sense, and there isn't a good way to handle this, right? Perhaps I might add some more helpful error messages, if you like.

I have an application which occasionally prints things to stdout while it is running. It's a radio transceiver driver GUI which prints what it receives. When the underlying app prints to stdout, it doesn't redraw the GUI. For completeness, here it is: https://github.com/barafael/ebyte-e32-ui but may be hard to reproduce without actual hardware :D

As the fine folks of clap have released clap v4, friends and me tried to go ahead and support clapv4 in klask.

Here's the fork: https://github.com/rust-nbg/klask

Doesn't work yet, but we'll be working on it on-and-off. Also I don't know if it would be possible/desirable to support both v3 and v4 somehow.

I was trying klask with this project: https://github.com/mazznoer/gradient-rs (I thought maybe it would make for a good showcase for this klask).

And the main window looks great as expected:

I have checked the list-presets option there. The output looks quite funny though:

In my terminal, it looks like this:

I'm not sure this is even in scope for klask, so just FYI :)