copied image files but changed to binary text

[wildan-pratama]

I'm using grim to copy take screenshot and copy it with wl-copy, but the image changes to binary text when pasting.
im using command "grim - | wl-copy" and same to when i copy image from file manager. maybe i forget installing some depedencies? im install wl-clipboard from arch repo. thanks before

[MMars-hall]

I'm having a similar issue
When i try copying an image from my browser or discord it always pastes as links
When i try to copy an image or video from the file manager it pastes as the path of the image or video
But when i try copying again and pasting it it works as normal

[bugaevc]

Hello,

but the image changes to binary text when pasting.

where are you pasting into, and how?

What does wl-paste --list-types output after you copy?

[cartok]

Hey I think I have the same issue, I can no longer copy paste images.

wl-copy < /home/cartok/Screenshots/screenshot_2023-10-09_10-07-34_769302616.png

wl-paste > foo.png
Clipboard content is not available as inferred output type "image/png"
Use "wl-paste --list-types" to view available types. Use "--type" to explicitly specify a type.

wl-paste --list-types
text/plain
text/plain;charset=utf-8
TEXT
STRING
UTF8_STRING

[bugaevc]

@cartok hi, does it work if you specify wl-copy --type image/png explicitly? What does xdg-mime query filetype /home/cartok/Screenshots/screenshot_2023-10-09_10-07-34_769302616.png print?

[cartok]

Hey @bugaevc thanks! Yes it works fine when specifying the type.

So the infering didn't work. Looked into the wl-copy man page. Found that xdg-mime is used. My issue is that I use xdg-utils-handlr a shim for xdg-utils to use handlr under the hood. Thing is that xdg-mime binary is not available with that package. Maybe it would be good if it would be a separate package or if that handlr package would offer a replacement.

I now uninstalled xdg-utils-handlr.

So In my case the issue is fixed. It would propably be best for other tools which make use of wl-clipboard to set the type explicitly if possible anyways. Noticed this because swayshot was no longer fully working.

[bugaevc]

It would propably be best for other tools which make use of wl-clipboard to set the type explicitly if possible anyways

Yes. This automatic type detection is primarily meant for interactive usage, so you can type wl-copy / wl-paste and have it typically do the right thing, and if you find it doing a wrong thing, correct it by passing --type explicitly. If a script knows that it will always be copying the same type of content (such as image/png), it really should pass --type image/png; this will both be faster because there's no need to detect the type, and more reliable, since there's no possibility of failing to detect the type (like in your case), or misdetecting the type.

Noticed this because swayshot was no longer fully working.

Perhaps you should file an issue with swayshot, telling them the above.

[cartok]

@wildan-pratama and @e0ra does this information also resolve your issues?

[bvr-yr]

but why not just use file --brief --dereference --mime-type, which almost every distro will have installed.

or as an alternative gio info -a standard::content-type,standard::name as it might give more precise detection, it seems to use shared-mime-info and also should be available as part of glib2. That makes it almost DE-independent.

the fact is that xdg-mime is just shellscript, which, if u look at, uses fallback logic kinda:
Desktop Environment tool > perl's mimetype module > file
which is kinda strange, cause it considers gio as Gnome tool

I also have handlr as a replacement for standard xdg-utils, and as workaround i just added simple wrapper script which calls file in my PATH.
but i see no reason to depend on xdg-mime, maybe just implement same fallback logic, or simply gio > file?
this will also remove overhead from redundant Desktop Environment checks

[cartok]

I did not test this yet but it sounds like a very good solution. Wdyt @bugaevc?

[bugaevc]

Yes, file --brief --mime (or something like that, --dereference certainly makes sense) is what I wanted to switch to. And the next release after the 2.2 series (so, 2.3) sounds like just the right time to do it. Hopefully I'll get to it some time soon, but also feel free to submit a PR without waiting for me.