Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rich content (Images, OpenOffice Text, etc) #130

Closed
YoloClin opened this issue Jun 5, 2020 · 2 comments
Closed

Rich content (Images, OpenOffice Text, etc) #130

YoloClin opened this issue Jun 5, 2020 · 2 comments

Comments

@YoloClin
Copy link

YoloClin commented Jun 5, 2020

I'm looking for a clipboard manager that supports rich content such as images, office text etc.

A simple way to reproduce the managing I'm looking for is: right-click an image in chrome/firefox, choose copy, paste it somewhere else - clipmenu doesn't persist the entry.

By default, clipmenu doesn't support this - any pointers on what's required to get it working or if it's even possible in X11?

@cdown
Copy link
Owner

cdown commented Jun 5, 2020

Hey there!

It's possible in X11 and is implemented by the target Atom for most requests. The problem is it requires a strong opinion on how and when to persist those requests. For example, with xclip you can put an image on the clipboard with xclip -selection clipboard -t image/png -i foo.png, and vice-versa with xclip -o, but then there are questions like which target atoms we should store -- if we store all of them, there's going to be a lot of duplication and overlap, and potentially some massive things to store unnecessarily. Copying from a browser stores a whole bunch of atoms, for example, that's why right now we only store UTF8_STRING.

Personally I don't really do WYSIWYG copy pasting, so I've never had it very high up on the priority list to implement. It's also a bit of minefield: some content types require an awareness of their nuances to store safely, and we'd have to decide how to represent them. I'm very aware that there is certainly a desire for it as a feature though.

I guess I'd be up for adding some kinds of rich content storage into clipmenu, but writing support for it and maintaining it would be somewhat up to those who want it -- I don't personally use it, so it's likely to receive significantly less testing than the rest of clipmenu.

So I guess the answer is "I'm fully in support of having that, but I'm unlikely to write the code for it myself", if that makes sense? :-)

@YoloClin
Copy link
Author

Hey thanks for the suggestion. After reading through https://www.uninformativ.de/blog/postings/2017-04-02/0/POSTING-en.html , your design decision makes a lot of sense.

As my use-case for rich copy/paste is somewhat limited I don't think it's worth my effort to implement this.

Thanks for your time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants