Mouse flag problems in record/capture commands

[ribosomerocker]

Describe the bug
There are a few issues I've encountered with the mouse flag:

1. Pairing it with the root flag seems to take the screenshot immediately, not listening to my mouse input, but it does capture transparency, so that's nice. It also seems to work fine when I try to delay the screenshot and go to a workspace without a desktop, unlike the following point.
2. Pairing it with the parent flag seems to work relatively as expected, it just doesn't show the overlay that it does by default, and it seems to error with:

[I] mon@artix-pc ~> menyoki -q cap --parent -m png save "-" | xclip -selection clipboard -t image/png
thread 'main' panicked at 'Failed to get the image', src/app.rs:415:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fish: Process 17789, 'menyoki' from job 1, 'menyoki -q cap --parent -m pn...' terminated by signal SIGABRT (Abort)

When I ran the command, switched to a different workspace that had no windows, and clicked on the wallpaper/desktop.

System Information

• OS: Artix linux 5.10
• Rust Version: 1.50
• Project Version: 1.2.1

[ribosomerocker]

Umm... I remember having a third problem about it but I think I've just forgotten about it... I'll try my best to remember it haha

[ribosomerocker]

Oh, I remember, it was a general thing: Why not add automatic testing to test the features you'll be adding onto your project, to minimise bugs and unexpected behvaiour?

[orhun]

1. Pairing it with the `root` flag seems to take the screenshot immediately, not listening to my mouse input, but it does capture transparency, so that's nice. It also seems to work fine when I try to delay the screenshot and go to a workspace without a desktop, unlike the following point.

--root and --focus flags doesn't set the --select implicitly so you have to specify them as well if you want to select a window.

--select        Select the window to capture

I'm not sure how this is related to transparency. It'd be nice if you can try something like menyoki rec --root --select -m and post results while I'm investigating this further.

2. Pairing it with the `parent` flag seems to work relatively as expected, it just doesn't show the overlay that it does by default, and it seems to error with:

When I ran the command, switched to a different workspace that had no windows, and clicked on the wallpaper/desktop.

menyoki tries to capture the parent of the selected window (if any) if --parent flag is provided. It also tries to draw the borders on that window so it might be expected for them to not seen in some cases. It was a feature that I added for window managers that put their content not on the actual window, but the parent. (#6)

The error you got was probably about the use of this flag or the fact that --mouse doesn't actually check if there's a window on the clicked area. (Like I said, it was a very basic implementation.) Because it seems like it couldn't get the image, which means in a sense it might not find any window to capture.

Oh, I remember, it was a general thing: Why not add automatic testing to test the features you'll be adding onto your project, to minimise bugs and unexpected behvaiour?

What exactly do you mean by "automatic testing"? Anything other than this?

[ribosomerocker]

Hmm, I sorta mean something like unit tests, where it tries to isolate some parts of the code and make sure the logic is fine, I forgot that you had automatic testing already set in-place haha, about the other errors, I more was reporting the fact that they weren't handled, and were just "raw" Rust errors.

[orhun]

Hmm, I sorta mean something like unit tests, where it tries to isolate some parts of the code and make sure the logic is fine, I forgot that you had automatic testing already set in-place [...]

A fair amount of code is being tested but it can always be extended. Maybe some features are not tested against all the combined cases. I should work on that more, for sure.

[...] about the other errors, I more was reporting the fact that they weren't handled, and were just "raw" Rust errors.

I see. I should eliminate the use of .expect("Failed to ...") on some common places.

[orhun]

Is this issue resolved? Did you have the chance to try it again?

[ribosomerocker]

Ah, right! I'm so sorry! I forgot that I kept this open... Thank you for the reminder!