### Problem description
WASM build does not support copy/paste beyond the application. Meaning,
there's no practical way of sending text back and forth across the
application border.
There are lengthy threads why this is a technical challenge in
WASM/Browser world, e.g:
- https://github.com/pthom/hello_imgui/issues/3
- https://github.com/emscripten-core/emscripten/pull/19510
### Implementation description
Implements a workaround solution as Header only C++ library, as proposed
and implemented at:
https://github.com/Armchair-Software/emscripten-browser-clipboard
Maybe there are cleaner ways of achieving the functionality. Definitely
would like to have some discussion around this. 👀ℹ️ The proposed PR "works for me" on Windows, using CTRL-C/V shortcuts
to copy text from and to the application. On MacOS the system shortcut
to Paste is different from what ImHex has defined. This results in
system Paste shortcut of command-V triggering the browser callback to
synchronise the application clipboard, but no actual Paste takes place
within ImHex.
If there would be a clean way to trigger the paste command, that would
be wonderful (or get the context and references to write the data to the
cursor, but I was unable to find a clean solution). The only proposed
solutions in the referenced threads were about triggering paste event
internally via Key events. This seemed wonky 🙃 , so is not currently
implemented. At the moment the paste on MacOS is command+V followed by
control+V.
### Additional things
This is definitely a stopgap solution before the ImGui and Emscripten
take a more proper solution in enabling Copy/Paste outside the
application borders. However, I feel like this is a must have capability
to make the WASM build more useful, not just for trying out ImHex.
Cheers! 🍻
---------
Co-authored-by: Nik <werwolv98@gmail.com>
Prior to this, at least on Linux/MacOS/etc, I guess it was not possible
to compile with Zstd included for `hex::dec::zstd_decompress()`:
Every other target lib for the decompression plugin would compile,
**except for** Zstd. Additionally, the target name `zstd` caused CMake
to not be able to find `Find(ZSTD).cmake` due to case-sensitivity
differences between Windows and Unix-based file paths, of course.
With that said, I'm not too sure if this will break building w/ Zstd on
Windows... Hopefully not 😄
