Here’s some things that I think I can help with.
Many Linux versions out of the box do not come with a clipboard manager. (Examples: Fedora and Ubuntu, though it looks like Kubuntu does have one)
This is kind of how I imagine clipboard works in these Linux: the window sending the data tells the OS that the program has been told to share clipboard data and the program hands over a hook/handle (the callback that actually serves the data) for the OS to hold onto.
When the receiver requests data of a certain mime-type, the sender’s callback packages the data up in that requested mime-type and sends it.
If the sender gets closed, then the callback is nullified. There is nobody to request information from, the data can’t be served to the pipeline, and nothing that gets sent.
A clipboard manager works by requesting and storing the data in multiple mime types and then makes the same request to the OS for control of the clipboard pipeline. The results are available for any receiver to request at a later time, even if the sender is closed because the manager has taken over the role of the sender.
If you wish to clear your clipboard, then use SDL_SetClipboardText(NULL); or SDL_CearClipboardData(); after processing the clipboard contents. I think the default behavior for most programs is to assume that the clipboard data might be needed by the user again and by other programs, so by default it’s not common practice to clear the clipboard after consuming the content… But if you offered a button that lets the user chose to clear the clipboard then this would be useful.
There is also this event you could listen for changes in the clipboard:
SDL_EVENT_CLIPBOARD_UPDATE = 0x900, /**< The clipboard or primary selection changed */
I think the code to the SDL_SetClipboardTextCallback function is outdated and there is no mime-handling inside this default callback. Whatever the reason, it doesn’t seem to process mime requests, and the default behavior is to send the data no matter what. If any type of mime request for data occurs, the text will be served. This is good reason to avoid SDL_SetClipboardText().
I don’t see any way to change the callback used by SDL_SetClipboardText, but you can still send text through SDL_SetClipboardData if you want to change this default behavior.
On the other hand: When you set up your own mime-handling callback for SDL_SetClipboardData, the docs say here that sending no data is somehow considered undefined behavior and might cause issue for some programs that aren’t set up to handle such an instance, which is also confusing. Perhaps this is more of a problem in some systems and not others?
All I can say is that if I have a portion of an image from Krita stored in clipboard and I request a text mime-type, I get NULL back as a pointer and the size is reported as zero. If I try to pass text to Krita while a portion of an image is selected, Krita is able to say that the data it was handed was not a png/bmp and ignores the paste request.
So just always be safe, if you request data from the clipboard in non-text format, then confirm that it’s not NULL, then confirm that it is indeed in that format before loading it into a surface/texture:
case SDLK_V:
{
// request paste;
size_t len = 0;
void * data = SDL_GetClipboardData("image/png", &len);
if(data)
{
unsigned char pngMagic[8] = {0X89, 0X50, 0X4E, 0X47, 0X0D, 0X0A, 0X1A, 0X0A};
if(strncmp((char*)data, (char*)pngMagic, 8) == 0)
{
SDL_Log("PNG Confirmed");
}
else
{
SDL_Log("The data is not PNG Formatted.");
}
}
else
{
SDL_Log("Data was NULL, length was %d", len);
}
}
break;
I could only replicate this kind of behavior when I wasn’t polling a window for events or rendering the window which lead to strange behavior, but the clipboard data and callbacks look to be tied to the window’s video device structure, so that kind of made sense at the time… Do you have example code to replicate this?