[SDL] SDL Clipboard API: Recommendations based on research

Jeremiah jerlark386 at gmail.com
Wed Jul 21 17:50:22 PDT 2010

On Wed, Jul 21, 2010 at 1:35 AM, Bob Pendleton <bob at pendleton.com> wrote:
> On Tue, Jul 20, 2010 at 3:09 AM, Sam Lantinga <slouken at libsdl.org> wrote:
>> Interestingly enough, I just implemented simple text clipboard support
>> in SDL 1.3 last week:
>> http://hg.libsdl.org/SDL/file/f8c3870af5a2/include/SDL_clipboard.h
>> I started playing around with images but that got complicated fast.
>> There's also a cross-platform difference between X11 and Windows and
>> Mac OS X: On Windows and Mac OS X you can inexpensively generate an
>> event when the clipboard contents changes.  As far as I can tell on
>> X11 you have to do a fairly expensive poll to achieve the same result.
>> Anyway, FYI...
> Yeah, it had to be that way. Windows and Mac OS were written with the
> assumption that the graphics system and the window manager are part of
> the OS and all applications run on the same machine that the graphics
> and  window manager are running on. X didn't make that assumption. X
> assumed that the graphics system (the X server) would run on one
> machine, the window manager could run on another machine, and each
> application might run on a different machine. So, when you cut and
> past on Windows/Mac the data only has to move from one part of memory
> to another on the same disk. On X if I cut from one application It has
> to be sent to the server over the network. A paste has to reach out to
> the server and ask for information. It would seem to be perfectly
> reasonable for the server to send every application an event when the
> clipboard changes. But, X has a subtext that was there from the
> beginning that doesn't seem to be in either Windows or Mac OS.It was
> always assumed that X would be used in high security environments. In
> environments like that each application has a security rating and an
> access list. (Am I allowed to say "Tempest" these days? Oh, just found
> it in Wikipedia :-)  If my application does a screen dump every thing
> on the screen that it isn't allowed to see (even icons) must be
> removed from the screen image before it is sent along to my
> application. If I cut from a low security app I may be able to paste
> into a high security app, but not the other way around. The existence
> of higher security applications must be hidden from low security
> applications and everyone else. I can't even send an event saying that
> something has been added to the clip board because if I do then
> someone tracking the mouse and sniffing the network would be able to
> detect that a high security application is running. That would tell
> someone when to start looking for "interesting" traffic on the
> network.
> You can't send an event to let an application know that something has
> been added to the clipboard because you might compromise national
> security.
> Whenever you run into something that makes no ()&)^&*_(^%)*_& sense in
> X it is most likely that simple logical way of doing things would
> create network traffic that could be correlated with other information
> to reveal the existence of a high security application and maybe even
> which pixels on the screen are occupied by that application. That
> information would allow the right kind of system to know which key
> strokes are going to the secure application. Security people are
> scary, very scary.
> Bob Pendleton
>> On Tue, Jul 13, 2010 at 11:22 PM, Nathaniel J Fries <nfries88 at yahoo.com> wrote:
>>> Okay, I haven't produced any code based on my research (other than text-only
>>> copy/paste on Windows and OS X, which is used in a GPL-licensed project).
>>> But here's what I've found that really affects the API:
>>> 1) Using the freedesktop.org (X11) clipboard method, copy/paste data is held
>>> in the CLIPBOARD selection and drag'n'drop data in the PRIMARY selection.
>>> 2) Drag'n'drop on Windows and Cocoa (OS X) requires a defined area.
>>> 3) This should already be known by Sam from his SDL_scrap work, but on X11
>>> you request clipboard data and then receive an X11 event with the requested
>>> data.
>>> 4) On all three systems, Images and Text are treated differently.
>>> Based on this, here's my suggestion on a Copy/Paste API:
>>> /* structures and enums, self-explanatory I'd think */
>>> typedef enum SDL_ClipType {
>>> } SDL_ClipType;
>>> typedef struct SDL_ClipData {
>>> SDL_ClipType type;
>>> Uint32 length; /* note: ignored in the case of an image */
>>> union {
>>> char* text;
>>> unsigned char* utf8;
>>> SDL_Surface* image;
>>> };
>>> } SDL_ClipData;
>>> /* functions */
>>> /* returns non-zero if clipboard data was available. The actual data will
>>> appear in the SDL Event queue */
>>> SDL_Bool SDL_RequestClipData(SDL_ClipType type);
>>> /* same as above, but you wait for the event (X11) instead. This will seem
>>> more normal to an application developer, and maybe should be just done like
>>> this anyway */
>>> SDL_Bool SDL_WaitClipData(SDL_ClupType type, void* buffer, Uint32 buflen,
>>> Uint32* size); /* alt: SDL_Bool SDL_WaitClipData(SDL_ClipType type,
>>> SDL_ClipData* data); */
>>> /* this function is pretty self-explanatory */
>>> void SDL_AddClipData(SDL_ClipType type, void* data, Uint32 length); /* alt:
>>> void SDL_AddClipData(SDL_ClipType type, SDL_ClipData* data); */
>>> /* clears the clipboard of all contents */
>>> void SDL_ClearClip();
>>> and we add a new event for receiving data from the clipboard:
>>> typedef struct SDL_ClipEvent {
>>> Uint8 type;
>>> SDL_ClipData data; /* alt: SDL_ClipType type; Uint32 length; union { char*
>>> text; unsigned char* utf8; SDL_Surface* image; }; */
>>> } SDL_ClipEvent;
>>> As for Drag'n'Drop:
>>> /* creates a new drag'n'drop region. returns an identifier for the region */
>>> Uint32 SDL_CreateDNDArea(SDL_Rect* rect);
>>> /* destroys the region */
>>> void SDL_DestroyDNDArea(Uint32 areaId);
>>> /* SDL application decided to start drag'n'drop-ing something */
>>> void SDL_BeginDND(Uint32 areaId, SDL_ClipData data); /* alt: void
>>> SDL_BeginDND{Text,Unicode,Image}(Uint32 areaId, SDL_ClipType type, Uint32
>>> len, {char* text, unsigned char* utf8, SDL_Surface* image}); */
>>> /* SDL application decides to clear DND data */
>>> void SDL_ClearDND();
>>> and again, new SDL events:
>>> /* when an item is dragged over a DND area */
>>> typedef struct SDL_DragOverEvent {
>>> Uint32 areaId;
>>> SDL_ClipData data; /* alt... you know, same as paste event */
>>> };
>>> /* when the user finally releases the mouse over a DND area */
>>> typedef struct SDL_DragDropEvent {
>>> Uint32 areaId;
>>> SDL_ClipData data; /* alt... you know, same as paste event */
>>> };
>>> Well, that's it. Hopefully whoever actually does this finds the information
>>> useful, and hopefully I don't bore anyone or leave them confused.
>>> ________________________________
>>> EM3 Nathaniel Fries, U.S. Navy
>>> http://natefries.net/
>>> _______________________________________________
>>> SDL mailing list
>>> SDL at lists.libsdl.org
>>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>> --
>>     -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
>> _______________________________________________
>> SDL mailing list
>> SDL at lists.libsdl.org
>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
> --
> +-----------------------------------------------------------
> + Bob Pendleton: writer and programmer
> + email: Bob at Pendleton.com
> + web: www.TheGrumpyProgrammer.com
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Then perhaps, SDL_Clipboard should be based on GTK/QT instead?

More information about the SDL mailing list