orhun / menyoki Goto Github PK

term_size is unmaintained; use terminal_size instead

The term_size crate is no longer maintained. Consider using
terminal_size instead.

See advisory page for additional details.

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

Describe the bug
Recording does not work

To Reproduce
Steps to reproduce the behavior:

1. Run menyoki record rec gif
2. See error

Expected behavior
The recording begins?

Screenshots/Logs

[2020-12-08T19:24:31 INFO menyoki::x11::window] Starting in 3[2020-12-08T19:24:31 INFO menyoki::util::command] Running the command...
thread 'main' panicked at 'Failed to run the command: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/app.rs:212:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fish : Tâche , 'LANG=C menyoki record rec gif' terminée par le signal SIGABRT (Abandon)

System Information

• OS: Arch Linux x86_64 5.9.9-arch1-1
• Rust Version: 1.48.0
• Project Version: 1.0.2

Additional context
N/A

Is your feature request related to a problem? Please describe.
I can't record to WebM.

Describe the solution you'd like
I'd like to record to WebM. Ideally in a MKV container.

Describe alternatives you've considered
Recording to WebP which is sadly also not availagle.

Additional context
pls gib webm

Describe the bug

Stop recording throw an error and does not generate any gif

To Reproduce
Steps to reproduce the behavior:

1. Start recording
2. Press the cancel key
3. An error is thrown and no gif is saved

Expected behavior
A gif should be created for the recording time

Screenshots/Logs

[2024-02-02T13:55:51 INFO menyoki::x11::display]
 Window title  -> "(?)"
 Window size   -> [828x385]
[2024-02-02T13:55:52 INFO menyoki::x11::display]
 Window title  -> "(?)"
 Window size   -> [828x715]
[2024-02-02T13:55:58 INFO menyoki::record] Recording 20 FPS...
[2024-02-02T13:56:00 WARN menyoki::record] User interrupt detected.
[2024-02-02T13:56:00 ERROR menyoki] Frame error: `No frames found to save`

System Information

• OS: [Arch Linux x86_64]
• Project Version: [1.7.0]
• xorg-server version: [21.1.11-1]

Is your feature request related to a problem? Please describe.
Throw exit status 1 when cancelling action(pressing Esc) to be able to use in scripts.

Example usage (this is bind to key e.g. PrtScr):

menyoki capture --root --select png && notify-send 'Screenshot taken`

Let's say I have decided to cancel operation, but notification will play always.

My usage:

menyoki -q capture --root --select png save "-" | tee "screenshot.png" | xclip -selection clipboard -t image/png && notify-send 'Screenshot taken`

If cancelled, this will create empty file + notification.

Describe the solution you'd like
Throw error/exit status by default or give option to throw it like --error.

Additional context
#21 #3

I just found out about menyoki and find it great as it allows me to record my computer enterily through the keyboard.

Since I'm often hitting the Escape key when using the softwares installed on my computer, I would like to change the keybinding for the cancel action. However, I couldn't find any information on how to so in the man pages of both the configuration and the command.

Is it possible to change the keybindings for the key other than the action key ? Especially the cancel key ?
If not, would this be implemented in the future ?

Potential segfault in the time crate

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

The affected functions from time 0.2.7 through 0.2.22 are:

• time::UtcOffset::local_offset_at
• time::UtcOffset::try_local_offset_at
• time::UtcOffset::current_local_offset
• time::UtcOffset::try_current_local_offset
• time::OffsetDateTime::now_local
• time::OffsetDateTime::try_now_local

The affected functions in time 0.1 (all versions) are:

• at
• at_utc
• now

Non-Unix targets (including Windows and wasm) are unaffected.

Patches

Pending a proper fix, the internal method that determines the local offset has been modified to always return None on the affected operating systems. This has the effect of returning an Err on the try_* methods and UTC on the non-try_* methods.

Users and library authors with time in their dependency tree should perform cargo update, which will pull in the updated, unaffected code.

Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.

Workarounds

No workarounds are known.

References

time-rs/time#293

See advisory page for additional details.

Describe the bug
In some cases menyoki might encounter an error and terminate itself without handling the error. (#20) For that, it often uses expect and it causes to print raw Rust errors. These cases should be handled more elegantly and errors should be printed to stdout with log::error macro.

To Reproduce
Steps to reproduce the behavior:

1. Run menyoki rec -f -c 0
2. Press ESC
3. See error:

thread 'main' panicked at 'No frames found to save', src/app.rs:453:28
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted (core dumped)

Expected behavior

[2021-03-09T11:20:04 ERROR menyoki::app] No frames found to save.

System Information

• OS: Arch Linux x86_64 5.11.2-arch1-1
• Rust Version: 1.50.0-stable
• Project Version: 1.2.1

Describe the bug
Invoking menyoki record returns seg fault.

[1] 358734 segmentation fault (core dumped) menyoki record

To Reproduce
Installed through
Expected behavior
A clear and concise description of what you expected to happen.

Screenshots/Logs
If applicable, add screenshots or logs to help explain your problem.

System Information

• OS: Manjaro Arch 5.11.16-1-ck-zen
• Rust Version: N/A
• Menyoki: 1.3.0
• XFCE desktop, AwesomeWM

Additional context
Only with the -r command, it invokes and completes successfully.

Describe the bug
It seems like most of the flags I'm trying to use do not behave as if they're supposed to, one of the things I kind of dislike is that menyoki doesn't implicitly set the q flag when it detects being piped to something, sort of like Bat(1), a Cat(1) clone in Rust.
Now, to a different problem: Say that you have a compositor that sets your windows' transparency by default, if you use something like:
menyoki -q cap --focus --with-alpha png save - | xclip -selection clipboard -t image/png
You will not get what was behind the window, because of it's transparency level, but you'll just get the window in normal transparency. What I thought I'd try to do that might incorporate my wallpaper, since that was what my goal was to include in my screenshot, was use the root option, but it cannot be used with focus , so I can't really get what the window actually looks like.

There's actually a raw X error that I recieve when I try:
menyoki -q cap --parent --root png save - | xclip -selection clipboard -t image/png
and I get the error even with just one of those flags, for both. I think this should be handled, like --root and --focus above.
In the same topic as raw X errors, it seems that the same as above, but replacing root with focus will generate the same effect.

One other thing I dislike is how long and sort of convoluted it makes your entire command to be, can you add in some ways to shorten more options, flags, and commands, maybe add in ways to do stuff easier than they can be done right now? I'd like if I just had to do:
menyoki cap -fa - | xclip -selection clipboard -t image/png, or maybe just try to make the copying part easier:
menyoki cap -Cfa, I believe this might be of very big help.
I'd also suggest making mouse-clicks work to select windows by default? It's really annoying to have to press Alt+S+Enter, it doesn't feel exactly like a sane default, IMHO.

One more thing, it for some reason looks like --with-alpha is completely useless, I'm not sure what the use for it is.
I was really interested in this project by the README, and I believe this could have pretty big potential, which is why I tested it and submitted this bug report. It looks like it's really nice.

Sorry if this felt more of a feature request than a bug report haha, I felt like I needed to say those things in here as well, I'd really appreciate it if this was made more easy to use and dependable.

System Information

• OS: Artix Linux 5.10.15
• Rust Version: 1.50.0
• Project Version: 1.2.1

Is your feature request related to a problem? Please describe.
Encoding WebP animations with the following command would be nice.

$ menyoki record webp

Describe the solution you'd like
Incorporate a WebP animation encoder crate (since image does not support it) and implement the encoder.

Describe alternatives you've considered
None.

Additional context
Also reported in #35

Is your feature request related to a problem? Please describe.
I use a dual monitor setup, and sometimes I would like to capture the whole of a single monitor. Currently it is possible by specifying --root --select and adjusting the selection to one monitor, but it would be nice to have an option to directly select a monitor

Describe the solution you'd like
A flag to select a monitor, preferably by screen id (or any other convenient way to reference a screen)

Describe alternatives you've considered
As mentioned above, the flags can be used to eventually capture a single screen. It may be possible to write a script to compute the appropriate parameters to capture one screen, but if it is feasible a flag would be preferable

Is your feature request related to a problem? Please describe.

Shell expressions are not expanded for input/output files.

$ menyoki edit "~/test.png"
[2023-05-10T19:50:30 ERROR menyoki] IO error: `No such file or directory (os error 2)`

Describe the solution you'd like

Use a crate such as shellexpand to handle these cases.

e.g. ~/test.png should be expanded as /home/orhun/test.png

Describe alternatives you've considered
None.

Additional context
None.

Really awesome tool! I'm wondering if aside from mp4 there will be support for mkv or othee video format.

Cheers

Is your feature request related to a problem? Please describe.

lodepng is a pure Rust PNG image decoder and encoder. Allows easy reading and writing of PNG files without any system dependencies.

We can support this crate as an alternative to the default PNG encoder.

Describe the solution you'd like

Add --lodepng flag to CLI/config and use lodepng encoder if it is set.

Describe alternatives you've considered
-

Additional context

We can make lodepng default if it is more performant.

Right now when you record anything, you can only see the window itself. The mouse pointer is not visible on the recording.

Just as an example, Peek has an option to record the mouse pointer:

Notice how I use my mouse to draw attention to a specific part of the screen! It's super useful 😇

ansi_term is Unmaintained

The maintainer has adviced this crate is deprecated and will not
receive any maintenance.

The crate does not seem to have much dependencies and may or may not be ok to use as-is.

Last release seems to have been three years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

• anstyle
• nu-ansi-term
• yansi

See advisory page for additional details.

When recording a gif I always have to trade off file size and smoothness of the recording. I think there's a way to do better.

In general, I expect smoothness when looking at small elements – mouse movements, dropdowns, etc. If, however, the entire screen is animated, it is OK for the framerate to drop significantly.

I wish there was a way to specify the framerate as a min and max value. For example, --min-fps 10 --max-fps 60 can mean that during high-bitrate moments, the gif will have an equivalent of 10 fps recording. However, at all other times, 60 fps can be maintained.

Regexes with large repetitions on empty sub-expressions take a very long time to parse

The Rust Security Response WG was notified that the regex crate did not
properly limit the complexity of the regular expressions (regex) it parses. An
attacker could use this security issue to perform a denial of service, by
sending a specially crafted regex to a service accepting untrusted regexes. No
known vulnerability is present when parsing untrusted input with trusted
regexes.

This issue has been assigned CVE-2022-24713. The severity of this vulnerability
is "high" when the regex crate is used to parse untrusted regexes. Other uses
of the regex crate are not affected by this vulnerability.

Overview

The regex crate features built-in mitigations to prevent denial of service
attacks caused by untrusted regexes, or untrusted input matched by trusted
regexes. Those (tunable) mitigations already provide sane defaults to prevent
attacks. This guarantee is documented and it's considered part of the crate's
API.

Unfortunately a bug was discovered in the mitigations designed to prevent
untrusted regexes to take an arbitrary amount of time during parsing, and it's
possible to craft regexes that bypass such mitigations. This makes it possible
to perform denial of service attacks by sending specially crafted regexes to
services accepting user-controlled, untrusted regexes.

Affected versions

All versions of the regex crate before or equal to 1.5.4 are affected by this
issue. The fix is include starting from regex 1.5.5.

Mitigations

We recommend everyone accepting user-controlled regexes to upgrade immediately
to the latest version of the regex crate.

Unfortunately there is no fixed set of problematic regexes, as there are
practically infinite regexes that could be crafted to exploit this
vulnerability. Because of this, we do not recommend denying known problematic
regexes.

Acknowledgements

We want to thank Addison Crump for responsibly disclosing this to us according
to the Rust security policy, and for helping review the fix.

We also want to thank Andrew Gallant for developing the fix, and Pietro Albini
for coordinating the disclosure and writing this advisory.

See advisory page for additional details.

Describe the bug
When starting a record/capture on the root window, the borders of the capture area are not visible. The selected area correctly shows up in the terminal, and completing the capture also saves the correct image (as per the selection shown in terminal)

To Reproduce
Steps to reproduce the behavior:

1. Run menyoki capture --root --select
2. Try resizing the capture area
3. The new dimensions are seen on the terminal, but the border cannot be seen

Expected behavior
The borders of the capture area should be seen even on the root window

Screenshots/Logs
N/A

System Information

• OS: Linux 5.4.0-58-generic Ubuntu 20.04 x86_64
• Rust Version: 1.50.0-nightly
• Project Version: 1.1.0
• X server version: 2:1.20.8-2ubuntu2.6
• WM: awesomeWM 4.3

Additional context
Previous discussion here

Describe the bug

[2020-12-02T15:58:54 WARN menyoki::x11::display] User interrupt detected.
thread 'main' panicked at 'Failed to get the window', src/app.rs:169:34
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted (core dumped, if enabled)

To Reproduce
menyoki capture then Esc

Expected behavior
Not doing that; something to the effect of let window = self.window?; instead or the equivalent where it's assigned, probably.

System Information

• OS: buster and sid
• Rust Version: rustc 1.48.0 (7eac88abb 2020-11-16)
• Project Version: e2f596b

Is your feature request related to a problem? Please describe.
I love the concept and would like to give it a try, but my Linux system is wayland-based 😞. Hope wayland support is added soon 🙏

Describe the solution you'd like
There are existing tools for wlroots-based compositors, like https://github.com/ammen99/wf-recorder and https://github.com/emersion/grim. Hope it helps you to figure out the implementation support for Wayland. I'll be glad to help out too if it's needed.

Describe the bug
When the gif is being saved, pressing ctrl +c to cancel it, does not have any effect.

[2024-02-02T13:42:06 INFO menyoki::gif] Saving... (30%)

This is an issue when there is a long capture that we want to cancel anyway.

To Reproduce
Steps to reproduce the behavior:

1. Run a capture
2. stop the capture
3. try to interrupt the saving process.

Expected behavior
The saving process should be stopped.

System Information

• OS: [Arch Linux]
• Project Version: [1.7.0]

Describe the bug
I tried to record webp but got the error below

oz-mint@ozmint-MACH-WX9:~/tmp/menyoki-1.7.0$ ./menyoki record webp
[2023-03-04T13:29:22 INFO menyoki::util::command] Running the command...
[2023-03-04T13:29:22 INFO menyoki::x11::window] Starting in 3[2023-03-04T13:29:22 ERROR menyoki] IO error: `No such file or directory (os error 2)`

To Reproduce
Steps to reproduce the behavior:

System Information

• OS: Linux Mint 21.1 Vera
• Project Version: 1.7.0

Is your feature request related to a problem? Please describe.
You currently recommend using slop in a subshell like --size $(slop) for being able to select a capture zone. However, this is quite awkward and I'd really like for menyoki to just include that. It seems an odd omission in a tool such as this which comes with so many batteries just to find of them to be weirdly missing.

Describe the solution you'd like
Include a bunch of flags such as --size-select, --size-cursor, --size-window and don't depend on external tools for this.

Describe alternatives you've considered
A tool such as peek which has this.

Additional context
🐱

Is your feature request related to a problem? Please describe.
Rust 1.56 is recently released with edition = "2021" and menyoki should be migrated from 2018 to 2021.

Describe the solution you'd like
cargo fix --edition

Describe alternatives you've considered
None

Additional context

• https://doc.rust-lang.org/edition-guide/rust-2021/index.html

Is your feature request related to a problem? Please describe.
While recording a long-lasting operation, the user might want to pause recording and then continue afterwards.

Describe the solution you'd like
Add a key binding for pausing the recording.

Describe alternatives you've considered
None.

Additional context
None.

Data race in Iter and IterMut

In the affected version of this crate, {Iter, IterMut}::next used a weaker memory ordering when loading values than what was required, exposing a potential data race
when iterating over a ThreadLocal's values.

Crates using Iter::next, or IterMut::next are affected by this issue.

See advisory page for additional details.

Is your feature request related to a problem? Please describe.
Supported platforms list should be extended by implementing the core features of menyoki on different systems.

Describe the solution you'd like
Implementing the window system functions of macOS operating system for grabbing a Window for record and capture actions.

Additional context

• Code of Conduct
• Implementation Details
• Contribution Guidelines

Describe the bug
I expected this command to record for 10 seconds and exit, but it didn't exit:

menyoki record -d 10 gif --fps 30 -s save x.gif

System Information

• OS: FreeBSD 14.0
• Rust Version: 1.74.1
• Project Version: 1.7.0

Describe the bug
When trying to select a window with either capture or record, it will only select the area excluding the top border, and if I had any on the sides I'd assume those would be missing too.

To Reproduce
Steps to reproduce the behavior:

1. Run menyoki capture
2. Select a window
3. See marked area excludes the window decorations

Expected behavior
The entire window to be captured

Screenshots/Logs
The top part of the window is cut off:

System Information

• OS: Arch Linux x86_64 5.9.14-zen1-1-zen
• Rust Version: 1.48.0-1 from [extra]
• Project Version: 1.1.0

user@personal:~$ menyoki record gif --fps 10
[2020-12-09T00:20:45 INFO menyoki::x11::display] 
 Window title  -> "(?)"
 Window size   -> [1x1]
[2020-12-09T00:20:45 ERROR menyoki::x11] BadMatch (invalid parameter attributes) [Opcode: 61, Serial: 19]
Selected area -> [1x1] 
...

Steps to reproduce

1. Get QubesOS R4.1 (most likely reproducible on R4.0 as well)
2. Create a new VM based on debian-11
3. In VM install package librust-x11-dev to avoid build failure (#7)
4. In VM install cargo to get rustlang backend
5. In VM Run cargo install menyoki
6. In VM Run menyoki record gif --fps 10 and expect failure highlighted above.

Additional information

Works on Flameshot

Using alternative flameshot called as flameshot gui works.

Effects of qubes-issues/6271

Might be affected by QubesOS/qubes-issues#6271

Hey - is it possible to output the captured buffer so you can pipe it to other commands (e.g. xclip)

Related: is there an existing way to copy a capture to the clipboard?

Cheers

Is your feature request related to a problem? Please describe.
See #52 #53

Describe the solution you'd like
The key bindings documentation can be improved to clear up possible confusions.

Describe alternatives you've considered
None.

Additional context
#52 (comment)

Describe the bug
I think the CLI is a bit awkward to use and overuses subcommands in favor of flags.

To Reproduce
For instance, menyoki record --root --size $(slop) apng save /tmp/hello.apng. This is somewhat awkward.

Expected behavior
How about menyoki record --size-select --format apng --output /tmp/hello.apng. I think this makes a lot more sense. We could also have a shortform -f apng -o /tmp/hello.apng.

Is your feature request related to a problem? Please describe.
I have a 2K (2560x1600px) screen 181x113 in size (8.4" diagonal). That's tiny and very very dense (primitive calculation says 360ish DPI or 14px/mm but I'm not sure if I'm counting right).

The default X DPI is 96 and XDrawString() doesn't respect the Xft.dpi resource that I use to offset the incredible minusculity of the text at default size for reasons I assume obvious. The text with the resolution at the centre is, quite literally, unreadable from more than a hand's width away from the screen.

Describe the solution you'd like
The solution is probably fontconfig?

Describe alternatives you've considered
I've tried to convince XDrawString() to use a different or bigger font via XSetFont(), but haven't had much success; this might be because it's too arcane for me, or I might be holding it wrong.

Additional context
Confer this YouTube video, resize to 113x181 for optimum viewing experience: https://youtu.be/D2xb2ijuxeQ (frankly, I'm having trouble on my 27" display).

I'm very much not opposed to implementing this myself, but, well, I might need a suggestion or two on how to proceed.

Describe the bug
Cannot capture images or select windows when using on dwm.

To Reproduce
Steps to reproduce the behavior:

1. Try capturing with menyoki capture or any other command
2. It only selects the terminal window from which the command is being run and when the keys Alt + Enter are pressed shows the image is being saved.
3. It shows a blank image when opened.

Expected behavior
Allow to select the window and capture it.

Logs
When I focus on another window and press Alt+Enter this was the output

[2020-12-07T16:04:09 DEBUG menyoki::x11] Record window: Focus(Some(Geometry { x: 0, y: 0, width: 0, height: 0 }))
[2020-12-07T16:04:09 DEBUG menyoki::x11::display] Window ID: 41943045
[2020-12-07T16:04:09 INFO menyoki::x11::display]
 Window title  -> "(?)"
 Window size   -> [1054x1057]
[2020-12-07T16:04:11 DEBUG menyoki::x11::display] Window ID: 18916785
[2020-12-07T16:04:11 INFO menyoki::x11::display]
 Window title  -> "(?)"
 Window size   -> [1x1]
[2020-12-07T16:04:11 ERROR menyoki::x11] BadMatch (invalid parameter attributes) [Opcode: 61, Serial: 1937]
[2020-12-07T16:04:17 DEBUG menyoki::x11::display] Selected window: Some(18916785)
[2020-12-07T16:04:18 DEBUG menyoki::app] File { path: "/home/zeus/menyoki/cap.png", format: Png }
[2020-12-07T16:04:18 DEBUG menyoki::app] Command: None
[2020-12-07T16:04:18 INFO menyoki::app] Capturing an image...
[2020-12-07T16:04:18 ERROR menyoki::x11] BadMatch (invalid parameter attributes) [Opcode: 61, Serial: 4405]
[2020-12-07T16:04:18 ERROR menyoki::x11] BadMatch (invalid parameter attributes) [Opcode: 61, Serial: 5906]
[2020-12-07T16:04:18 ERROR menyoki::x11] BadMatch (invalid parameter attributes) [Opcode: 73, Serial: 5907]
thread 'main' panicked at 'Failed to get the image', src/app.rs:414:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted (core dumped)

System Information
Linux 5.9.11-arch2-1 x86_64 GNU/Linux
WM : DWM 6.1
Additional context
I'm using a dual monitor setup and can take the screenshot of the entire screen spanning 2 monitors. But it should be possible to capture and record individual windows.

I'm getting the following errors when trying to build locally or install through cargo install.
Running Void Linux (glibc). pkg-config is installed.

> uname -a
Linux void 5.9.12_2 #1 SMP 1607140463 x86_64 GNU/Linux

> cargo build
   Compiling addr2line v0.14.0
   Compiling imagequant-sys v2.13.1
   Compiling x11 v2.18.2
   Compiling crossbeam-utils v0.8.1
   Compiling num_cpus v1.13.0
   Compiling getrandom v0.1.15
   Compiling atty v0.2.14
   Compiling time v0.1.44
   Compiling term_size v0.3.2
error: failed to run custom build command for `x11 v2.18.2`

Caused by:
  process didn't exit successfully: `/home/kkga/repos/menyoki/target/debug/build/x11-0088155ec7df5726/build-script-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-env-changed=X11_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=X11_STATIC
  cargo:rerun-if-env-changed=X11_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Failure { command: "\"pkg-config\" \"--libs\" \"--cflags\" \"x11\" \"x11 >= 1.4.99.1\"", output: Output { status: ExitStatus(ExitStatus(256)), stdout: "", stderr: "Package x11 was not found in the pkg-config search path.\nPerhaps you should add the directory containing `x11.pc\'\nto the PKG_CONFIG_PATH environment variable\nNo package \'x11\' found\nPackage x11 was not found in the pkg-config search path.\nPerhaps you should add the directory containing `x11.pc\'\nto the PKG_CONFIG_PATH environment variable\nNo package \'x11\' found\n" } }', /home/kkga/.cargo/registry/src/github.com-1ecc6299db9ec823/x11-2.18.2/build.rs:36:67
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed

> cargo install menyoki
[...]
error: failed to run custom build command for `x11 v2.18.2`

Caused by:
  process didn't exit successfully: `/tmp/cargo-installBWYeYv/release/build/x11-25ea6e890a1fdb77/build-script-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-env-changed=X11_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=X11_STATIC
  cargo:rerun-if-env-changed=X11_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
  cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_PATH
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
  cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Failure { command: "\"pkg-config\" \"--libs\" \"--cflags\" \"x11\" \"x11 >= 1.4.99.1\"", output: Output { status: ExitStatus(ExitStatus(256)), stdout: "", stderr: "Package x11 was not found in the pkg-config search path.\nPerhaps you should add the directory containing `x11.pc\'\nto the PKG_CONFIG_PATH environment variable\nNo package \'x11\' found\nPackage x11 was not found in the pkg-config search path.\nPerhaps you should add the directory containing `x11.pc\'\nto the PKG_CONFIG_PATH environment variable\nNo package \'x11\' found\n" } }', /home/kkga/.cargo/registry/src/github.com-1ecc6299db9ec823/x11-2.18.2/build.rs:36:67
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to compile `menyoki v1.0.1`, intermediate artifacts can be found at `/tmp/cargo-installBWYeYv`

Caused by:
  build failed

Is your feature request related to a problem? Please describe.
Supported platforms list should be extended by implementing the core features of menyoki on different systems.

Describe the solution you'd like
Implementing the window system functions of Windows operating system for grabbing a Window for record and capture actions.

Additional context

• Code of Conduct
• Implementation Details
• Contribution Guidelines

Describe the bug
Cargo installation errors and fails to install.

To Reproduce
Steps to reproduce the behavior:

1. cargo install menyoki

Expected behavior
menyoki should be installed

Screenshots/Logs

    Updating crates.io index
  Installing menyoki v1.0.1
   Compiling autocfg v1.0.1
   Compiling libc v0.2.81
   Compiling cfg-if v1.0.0
   Compiling lazy_static v1.4.0
   Compiling cfg-if v0.1.10
   Compiling byteorder v1.3.4
   Compiling const_fn v0.4.3
   Compiling bitflags v1.2.1
   Compiling crc32fast v1.2.1
   Compiling adler v0.2.3
   Compiling scopeguard v1.1.0
   Compiling adler32 v1.2.0
   Compiling rayon-core v1.9.0
   Compiling proc-macro2 v0.4.30
   Compiling getrandom v0.1.15
   Compiling proc-macro2 v1.0.24
   Compiling bytemuck v1.4.1
   Compiling unicode-xid v0.2.1
   Compiling color_quant v1.1.0
   Compiling unicode-xid v0.1.0
   Compiling syn v1.0.54
   Compiling either v1.6.1
   Compiling syn v0.15.44
   Compiling pkg-config v0.3.19
   Compiling ppv-lite86 v0.2.10
   Compiling num-derive v0.2.5
   Compiling weezl v0.1.3
   Compiling cc v1.0.66
   Compiling maybe-uninit v2.0.0
   Compiling failure_derive v0.1.8
   Compiling gimli v0.23.0
   Compiling lzw v0.10.0
   Compiling unicode-width v0.1.8
   Compiling scoped_threadpool v0.1.9
   Compiling rustc-demangle v0.1.18
   Compiling nix v0.18.0
   Compiling object v0.22.0
   Compiling ahash v0.4.6
   Compiling log v0.4.11
   Compiling ansi_term v0.11.0
   Compiling vec_map v0.8.2
   Compiling imgref v1.7.0
   Compiling strsim v0.8.0
   Compiling natord v1.0.9
   Compiling wild v2.0.4
   Compiling input-event-codes v0.2.1
   Compiling quick-error v2.0.0
   Compiling mutate_once v0.1.1
   Compiling dunce v1.0.1
   Compiling bytesize v1.0.1
   Compiling dominant_color v0.3.0
   Compiling hex v0.4.2
   Compiling miniz_oxide v0.3.7
   Compiling inflate v0.4.5
   Compiling rgb v0.8.25
   Compiling gif v0.11.1
   Compiling gif v0.10.3
   Compiling hashbrown v0.9.1
   Compiling kamadak-exif v0.5.2
   Compiling crossbeam-utils v0.8.1
   Compiling num-traits v0.2.14
   Compiling memoffset v0.6.1
   Compiling miniz_oxide v0.4.3
   Compiling num-integer v0.1.44
   Compiling rayon v1.5.0
   Compiling num-iter v0.1.42
   Compiling crossbeam-utils v0.7.2
   Compiling num-rational v0.2.4
   Compiling num-rational v0.3.2
   Compiling resize v0.5.5
   Compiling gif-dispose v3.0.1
error[E0599]: no method named `to_int_unchecked` found for type `f32` in the current scope
   --> /home/asheboy/.cargo/registry/src/github.com-1ecc6299db9ec823/resize-0.5.5/src/px.rs:185:45
    |
185 |             (0f32).max(f.round()).min(255.).to_int_unchecked()
    |                                             ^^^^^^^^^^^^^^^^ method not found in `f32`

error[E0599]: no method named `to_int_unchecked` found for type `f32` in the current scope
   --> /home/asheboy/.cargo/registry/src/github.com-1ecc6299db9ec823/resize-0.5.5/src/px.rs:199:47
    |
199 |             (0f32).max(f.round()).min(65535.).to_int_unchecked()
    |                                               ^^^^^^^^^^^^^^^^ method not found in `f32`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0599`.
error: could not compile `resize`.

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: failed to compile `menyoki v1.0.1`, intermediate artifacts can be found at `/tmp/cargo-install5nci6h`

Caused by:
  build failed

System Information

❯ lsb_release -a
No LSB modules are available.
Distributor ID: Neon
Description:    KDE neon User Edition 5.20
Release:        20.04
Codename:       focal

❯ cargo --version
cargo 1.43.

Potential segfault in localtime_r invocations

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

Workarounds

No workarounds are known.

References

• time-rs/time#293

See advisory page for additional details.

Running the latest linux-musl executable does not work.

To Reproduce
Steps to reproduce the behavior:

1. Download menyoki-1.2.0-x86_64-unknown-linux-musl.tar.gz
2. Extract tar xfv ... and cd menyoki-1.2.0
3. Run ./menyoki

Expected behavior
The menyoki usage is displayed.

Screenshots/Logs
-bash: ./menyoki: No such file or directory

System Information

• OS: Debian 9.3 64bit
• Rust Version: -
• Project Version: 1.2.0