Add image support

[shasherazi]

It would be better if I could see my copied images in clipmenu too. Since it is not a graphical program, this might be a bit tricky, I think. We can use some sort of indicator, at least, for image items in clipmenu maybe?

[zefr0x]

When you copy an image, you are not coping it in reality. It will not be copied tell you paste it.

This is the default behavior of text also when you are not using a clipboard manager. If you closed the application that you copied the thing from before pasting the thing, you will not be able to past it, because you can no longer request the application to copy the thing.

The clipboard manager will make this easier and user friendly by running in the background and coping every thing by it self to it's memory, so when you request something, you will request the clipboard manager (that is always running), not the application that you copied from. This will enable you to past things even after closing an application.

As I can see, the problem is not just thet clipmenu is not displaying images, but it is not saving anything other then text. The problem with images and other files that they might be very huge in size, and that there are a lot of file types, so usually clipboard managers will not save them or might set a size limit for them.

I don't know what do the maintainer of the project think, but I think that this will make the project a little bit complex.

Maybe it is possible to just copy the request data without coping the image by it self.
But now we will also need to monitor every application to see if images are still accessible or we need to delete them from the list.
I can see how can this be more and more complex.

[zefr0x]

Related issue: #130

[cdown]

I considered this for the C rewrite in 70cc5d2 and in the end decided to not add features for now, but it is certainly possible. What's needed:

• INCR support (both in and out)
• Some idea how it would be displayed in clipmenu
• Some way to work out which targets we want without duplicating everything and wasting a bunch of space

[9xcode]

I think one possible approach could be to store images temporarily as files and just reference them in the clipmenu list instead of holding the binary data directly in memory.
For example, when an image is copied, the clipboard manager could dump it into a cache directory (like ~/.cache/clipmenu/images/) and store only a small text marker in the history file, something like [image/png] saved as clip_001.png.

Then, when selecting that entry, clipmenu could pipe it back to the clipboard using xclip -selection clipboard -t image/png -i ~/.cache/clipmenu/images/clip_001.png.
That way, it won’t waste memory or break existing behavior, but users can still reselect copied images.

This wouldn’t need full GUI preview support, just a clear marker that it’s an image entry, maybe with the MIME type or file path shown in the menu.

[N-R-K]

I used to use greenclip before clipmenu and it had image support. IIRC it only supported a single image in the store (i.e if you copy another image, then the last image entry will be lost) and had some kind of marker that indicated it was an image and not text entry.

One big reason why I stopped using greenclip is because the image copy was really cpu intensive and would cause the application to lag for large images (e.g firefox would freeze if I tried to paste an image above >720p-ish from greenclip into it).

For this reason, it also had a limit of 500kb for images, if you tried to copy anything larger, it would silently refuse. I would often get cases where I copy an image, only to later find out it didn't actually get stored into the clipboard due to size.

Since the image copy was the only advantage greenclip had over clipmenu (imo) and it wasn't even functioning well, I decided to ditch it.

Anyways, what I'm basically getting at here is that if we decide to add image support, we'll want to see if there's a way to make it function fast without lagging/freezing (using linux specific syscalls if needed). Otherwise, if it freezes/lags/is unreliable, then it's basically going to be a bigger annoyance than worth.

[9xcode]

i think the idea i have provided above will work, because here we are not saving copyed image bytes in memory instread we are saving the image at the specific location (Directory that contains all the histrory for clipmenu), and then just add the image reference to the history so next time when we sleect any entry (image entry) from the clipmenu history it will just copy that specific image to the clipboard and then we can paste it anywhere.

the only tradeoff with clipmenu is that we don't have native image preview feature, but i think we even don't want that feature.

and whenever system boot next time it will clear all the history.

i'm curious if you have any better plan or if any issue with my plan that i am not recognized yet.

@N-R-K @cdown @anyone

[thoughtsunificator]

@N-R-K I have the same issue with clipmenu, can't hope much for images that are more than 1mb even with high-end cpus.

X11 (large) images pasting makes everything crash/freeze/block UI and this is even worse when you do it in a browser (reverse image search using clipboard for example)

In theory, @9xcode solution should improve things quite a bit.

[cdown]

I have the same issue with clipmenu, can't hope much for images that are more than 1mb even with high-end cpus.

With greenclip right? We should ignore images.

[N-R-K]

I think one possible approach could be to store images temporarily as files and just reference them in the clipmenu list instead of holding the binary data directly in memory

The issue is getting the image and then sending it when it's pasted. It needs to be sent thru the X server which is the bottleneck. Whether or not the image is held in memory or file is not the issue, the transfer is.

Maybe there's some kind of shared memory extension or something that can bypass the transfer/do it more efficiently, but I don't see anything from a quick search.

[thoughtsunificator]

~~No, I have the same issue with both~~

[N-R-K]

No, I have the same issue with both.

Clipmenu doesn't deal with images at all. The issue you're describing most likely has to do with image pasting in general, not really related to clipmenu.

[thoughtsunificator]

Yes, my mistake.

…

On Wed, Feb 04, 2026 at 09:03:25AM -0800, NRK wrote: N-R-K left a comment (cdown/clipmenu#196) > No, I have the same issue with both. Clipmenu doesn't deal with images at all. The issue you're describing most likely has to do with image pasting in general, not really related to clipmenu. -- Reply to this email directly or view it on GitHub: #196 (comment) You are receiving this because you commented. Message ID: ***@***.***>

-- Cordialement, Romain LEBESLE.

[cdown]

It looks like one thing we can do is do it with text/uri-list, but of course the receiving application must support this. And again we must work out how to best represent this to the user in clipmenu.