Pasting large images

[tcftbl]

I have problem where an application freezes or ignores pasting when pasting big enough picture from clipboard. It happens with pictures of size >2.8MB but not with size <280KB. This only happens when clipmenud is running and even the large pictures work fine without it. This seems to be related to #167, but is not limited to taking screenshots.

I think that the reason reproduction didn't work in #167 was the file size. In that issue it was suggested that the problem lies with xsel. That is likely the case but this issue (if it's the same issue) seems to be affecting several users, so I think it is appropriate to raise another issue here.

How should we go about investigating this?

I'm using arch with clipmenu version 6.2.0-2, xsel version 1.2.0.20200527-1 and clipnotify version 1.0.2-2. I use xclip to copy pictures to the clipboard.

[tcftbl]

I did a little digging in the clipmenud code and found out the offending command. xsel -o --clipboard seems to hang when there is a too large picture in the clipboard. I filed a bug report to xsel, but at the same time I was wondering if there is an elegant solution to avoid this problem in clipmenu.

[cdown]

Hi! Thanks for digging, sorry for the late reply.

I think it might be time to move to xclip, which has -t UTF8_STRING to make it clear which types of content we want to look for.

Does dbb5ce9017cfce08384bbfcd18e715f28dcfde44 make things better for you?

[tcftbl]

dbb5ce9017cfce08384bbfcd18e715f28dcfde44 seems to work nicely with large pictures. However, there seems to be a little side effect. Previously when running clipmenu the list didn't include any previously copied images. After dbb5ce9017cfce08384bbfcd18e715f28dcfde44 on the other hand clipmenu seems to list the images in as a multiline binary mess.

Is it preferable to leave this behaviour as is or should clipmenu ignore pictures entirely?

[cdown]

Thanks for getting back! Well that's... weird, I don't expect UTF8_STRING to get populated when there's an image. I'll investigate more, thanks.

[tcftbl]

The issue only comes up for me when I use xclip to copy pictures (not for example when copying pictures with an internet browser) by using the command xclip -selection clipboard -t image/png -i image.png. I'm not super familiar with xclip so it could be that I'm just misusing it.

Happy to help and thanks for continuing to maintain this very useful program!

[cdown]

That's particularly weird because UTF8_STRING isn't even listed in TARGETS. With -verbose, one sees that it's being converted, I guess?

% xclip -verbose -debug -selection clipboard -t UTF8_STRING -o  >/dev/null
Connected to X server.
Using selection: XA_CLIPBOARD
Using UTF8_STRING.
Type is image/png.

One option is to look at TARGETS to see if UTF8_STRING is advertised, but this is racy. On a normal case, one sees:

% xclip -verbose -debug -selection clipboard -t UTF8_STRING -o >/dev/null 
Connected to X server.
Using selection: XA_CLIPBOARD
Using UTF8_STRING.
Type is UTF8_STRING.

[cdown]

Ah, so it's just freely interpreting:

% xclip -verbose -debug -selection clipboard -t DOESNOTEXIST -o >/dev/null 
Connected to X server.
Using selection: XA_CLIPBOARD
Using DOESNOTEXIST.
Type is image/png.

xclip HEAD errors out on this, albeit not very gracefully:

xclip: Error: window id 0x1e00001 cannot convert CLIPBOARD selection to target 'DOESNOTEXIST'

[iambeingtracked]

I have the same problem. It especially bothers me with fullscreen shots on a 2k monitor

By the way, is it possible to get that image out of clipboard? Like to an image file

[cdown]

This should be fixed with the new C rewrite of clipmenu{,d} -- it ignores things which cannot become UTF8_STRING. Please feel free to try out 70cc5d2b6a2027ba186f1555c0e114c53dc7c578 and let me know how it goes.

[cdown]

Closing without prejudice, any problems let me know and I'll reopen :-)