Clipboard API missing temporal order

[Green-Sky]

The current, new clipboard api with added support for types other than text is a really good thing.
But, it lacks info on what was set last. eg:
(assume set is externally)

1. text is set
   -> no issue yet, we only know of text
2. file is set (like an image)
   -> now both, text and file are set, with no way to know what was the last copy, so we cant know , whether we should paste the file or the text.
3. i set text again
   -> same issue, but now text would be the correct answer.

[Green-Sky]

Ideas on how to solve this:

1. add mime type to the SDL_EVENT_CLIPBOARD_UPDATE event
2. add some way to query the timestamp of last set for a mimetype -> since most clipboard copy operations on files set multiple mimetypes

[slouken]

Good point, thanks for the feedback!

[Green-Sky]

Took a deeper look, because the primary selection feature is somewhat broken on X11.
The reason for the clipboard to not update is indeed because we loop over the list of known text mime-types until we find one, without looking at any timestamps.

Further, primary selection does not work for most apps I care about (terminals like xterm and alacritty), because only the first text mime-type in the list is looked at. Converting this to a loop would only fix this partially, same as current clipboard behavior.

[Susko3]

You mention that all the sets are external. Isn't it the operating systems's job to clear out stale clipboard data? On Windows, this is delegated to applications: they must call EmptyClipboard to empty and take ownership of the clipboard.

Unless SDL is somehow caching the clipboard content (that would be really inefficient).

[Green-Sky]

External applications, and also SDL can and will set different data for different mimetypes for what the user sees as a single clip on the board. Copying image data usually sets png, jpg, bmp and other formats, each technically being their own. Now you can mix in text in there, on linux there is also a selection clipboard, that works the same but should not be touched and continue to be valid when other mimetypes are set.

[Susko3]

Everything you said is correct and makes sense (and helped me understand what the primary selection text is), but it doesn't address my question.

[c-smile]

The current, new clipboard api with added support for types other than text is a really good thing.

Yes, but mime types are not that portable for these purposes.

Take images for example, Windows and MacOS have their own internal formats for clipboard and DnD (CF_DIB and NSImage serialization). MSPaint will put CF_DIB into clipboard. What mime type you will use to get that?

Check this

[slouken]

Fixed!