Screenshot tool does not save to clipboard #54

Closed
opened 2023-12-27 01:30:36 -08:00 by triantares · 4 comments

Using version 0.25.4 git20231114

When using the builtin screenshot tool, the "copy" button does nothing at all.

Using version 0.25.4 git20231114 When using the builtin screenshot tool, the "copy" button does nothing at all.
Owner

it copies the image to the clipboard. only some apps understand this - libreoffice for example does. ctrl+v in libreoffice and you'll see the image pasted after you pressed copy.

it copies the image to the clipboard. only some apps understand this - libreoffice for example does. ctrl+v in libreoffice and you'll see the image pasted after you pressed copy.
Author

Hmm, you're right it does copy into LibreOffice (and Thunderbird) but doesn't show up in other apps like the web-browser, any text-editor, diodon or terminal.
Most screenshooters (i.e "flameshot") do do this correctly.

Where's the difference coming from?

Hmm, you're right it does copy into LibreOffice (and Thunderbird) but doesn't show up in other apps like the web-browser, any text-editor, diodon or terminal. Most screenshooters (i.e "flameshot") do do this correctly. Where's the difference coming from?
Owner

efl offers the content with a ime type of image/something like image/png or image/jpeg - if the other end tries to fetch the selection with this format then that data is offered to the other end. copy & paste is a cooperative process. both sides the copier and the paster) need to share at least one format in common and agree on it and understand it and handle it... efl (which e uses) offers the image data as an encoded image of some sort as above - and can offer THAT to the other end to read and then decode and use. it's up to the other end to handle what efl/e is offering. as such the ime types offered are all mixed up and the assumption the other end will just handle any image format as e will offer either png or jpeg as the actual encoded data depending on quality - but the mime types offered will be a wide rtange of formats, so the other end has to be "not picky". you'll find chrome will paste it if you choose 100% qualty (ie it is a png). it won't handle jpegs (less than 100% quality).

efl offers the content with a ime type of image/something like image/png or image/jpeg - if the other end tries to fetch the selection with this format then that data is offered to the other end. copy & paste is a cooperative process. both sides the copier and the paster) need to share at least one format in common and agree on it and understand it and handle it... efl (which e uses) offers the image data as an encoded image of some sort as above - and can offer THAT to the other end to read and then decode and use. it's up to the other end to handle what efl/e is offering. as such the ime types offered are all mixed up and the assumption the other end will just handle any image format as e will offer either png or jpeg as the actual encoded data depending on quality - but the mime types offered will be a wide rtange of formats, so the other end has to be "not picky". you'll find chrome will paste it if you choose 100% qualty (ie it is a png). it won't handle jpegs (less than 100% quality).
Author

Aah, thanks for that clarification. :)

Aah, thanks for that clarification. :)
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: enlightenment/enlightenment#54
No description provided.