Skip to content
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.

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

provide option for rfd in hooks #102

Open
coderedart opened this issue Mar 3, 2022 · 4 comments
Open

provide option for rfd in hooks #102

coderedart opened this issue Mar 3, 2022 · 4 comments

Comments

@coderedart
Copy link

color eyre is great for command line apps, but gui apps, usually there's no terminal where you can display the output. it would be nice if we could enable a "rfd" feature or something, so that the report is shown in an error dialogue rather than the invisible console.

@yaahc
Copy link
Collaborator

yaahc commented Mar 3, 2022

I'm not familiar with what "rfd" means in this context or how exactly that would be accomplished. My expectation though is that if you wanted to write to a error dialog you'd have some sort of adapter where you just write the content of the Report to the dialog rather than having it somehow redirect to a dialog automatically when you print it.

As a strawman example, here's what I'd imagine doing this if I were writing an app using dialogs

let dialog = get_some_write_type_for_the_dialog();
write!(dialog, "Error: {:?}", my_report)?;

Panics on the other hand aren't as easy to redirect to a dialog. I believe we have some machinery for accessing the panic reporting logic itself rather than the panic hook, so you can actually change where you output to, so this should also be possible but I'd have to look into how.

So I guess generally I'm not opposed to this but I'd want to start with creating an example for how this would work, and my expectation is that we wouldn't need to do this as a feature, but if in the process of setting up the example we find that we would then I'm entirely on board with supporting that. I do think it's important that eyre/color-eyre serve gui use cases well.

@coderedart
Copy link
Author

rfd is the popular file dialog crate https://github.com/PolyMeilex/rfd . it is sort of like a port of https://github.com/mlabbe/nativefiledialog .

one of the main purpose of the library is to open file dialogs or show message boxes like a crash reporter. before using color_eyre, I used to simply set a panic handler like below

rfd::MessageDialog::new()
                    .set_title("App Crash")
                    .set_description(&format!("{}", &e)) // e is the panic load. its not much of a color_eyre::Report, but its something :D
                    .set_level(rfd::MessageLevel::Error)
                    .set_buttons(rfd::MessageButtons::Ok)
                    .show();

and the plan as that if the app panics, users could just send a screenshot or copy the text from the dialog box and come to discord or github issues complaining about it. having a report (which we have for cmdline right now) would be a huge help in narrowing down the issue.

for example, if we open a bunch of files over the lifecycle of an app, and we crash at some point, we could just check the trace to see which file was missing.

I wanted it to be behind a feature flag because it has a lot of dependencies (as it works on all platforms including browser/wasm).

@yaahc
Copy link
Collaborator

yaahc commented Mar 3, 2022

Okay, so I wrote up an example of how I'd do this in #103, can you take a look at that and let me know if it fits your usecase?

When I run it I get this output:
Screenshot from 2022-03-03 11-40-11

I had to disable the color theme because the dialog box doesn't seem to support ansi color-codes but it should work fine otherwise.

@coderedart
Copy link
Author

aye, that's exactly what i wanted. now everytime the app crashes, I will have a clear indication of where something went wrong even before i check the log files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants