The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

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_TEXT,
SDL_CLIPTYPE_UTF8,
SDL_CLIPTYPE_IMAGE
} 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.

I like it.  Would SDL push events even on systems which don't work that way just to unify the interface?

Jonny D


On Wed, Jul 14, 2010 at 2:22 AM, Nathaniel J Fries wrote:

That was the idea. It'd be simple enough to do. Slightly simpler than just pushing the other X11 events into the queue until we get the paste information, though not much. May not be enough to warrant it. The application developer would probably prefer the interface where we wait, though, and since most platforms (as well as most libraries offering clipboard functions) work like that, it may be better to just work like that anyway.

On 7/13/10, Nathaniel J Fries wrote:

I hope you incorporated my ideas in your research.
http://playcontrol.net/ewing/jibberjabber/SDL_ClipboardPrototype.html
There's a working implementation for Windows and OS X than SDL_scrap.
But drag-and-drop is not directly addressed.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

A couple of quick comments.

Using the word "clip" without a modifier is potentially confusing in a
graphics library. "Clip" has a strong connotation in the graphics
world. I would suggest using ClipBoard or even CB, but not just clip.

The functions used to wait for clip board data seem superfluous to me,
and just a little bit dangerous. You don't ever want to wait for a
specific event in an interactive program.

Do you really need a drop event and what I am guessing is a paste
event? Does it matter to me what the user is doing to get the data to
me? If I get an event that tells me that data is available and I have
a way to get that data why do I care if it is the result of a drag and
drop or a paste? The OS, may make a distinction. But that doesn't mean
that a programmer using SDL should have too.

Bob Pendleton



On Wed, Jul 14, 2010 at 1:22 AM, Nathaniel J Fries wrote:



--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ web: www.TheGrumpyProgrammer.com
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On 7/14/10, Bob Pendleton wrote:

I agree "Clip" is a bad idea. Mac actually uses the name Pasteboard.
In my prototype, I spell out clipboard. Everybody generally
understands the term/context clipboard.


Very good points Bob. I was thinking this too, but you said it much
better than I would have.

In my Clipboard prototype, I am completely detached from any events. I
think that is a much better model. You copy to the clipboard when you
want to send data. And you pull from the clipboard when you want to
retrieve data. No polling involved. No surprises involved.

Generally copy and paste are user initiated. I don't want all the text
I am currently typing to automatically go to the clipboard nor to I
want images to suddenly paste in my text body that I didn't request
because some background application may have decided to make something
available to the clipboard.

My API does not talk about Drag-and-Drop because I was focusing on
purely clipboard functionality. They are similar D&D probably end up
being built on top of the clipboard, but we should be careful to not
mix them up.

-Eric
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Thu, Jul 15, 2010 at 1:59 AM, Eric Wing wrote:

Hey, thanks, I work hard to be clear and concise.


Sound good to me. I think the main difference between drag and drop
and cut and paste are the types of data you can be handed. C&P rarely
gives you a group of files, but D&D can give a whole hoard of trolls
(ooops wrong D&D...) a whole group of files and directories. I suppose
the reason for keeping C&P and D&D separate is because the OSes have
different APIs for C&P and D&D. Hmmm, it seems to me that if you put a
transaction ID in the event and required the program to pass that ID
back to your API then you could hide the difference between the two.

Bob Pendleton





--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ web: www.TheGrumpyProgrammer.com
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I can see what you mean. They may mistake it with ClipArt or something. Well, I would hope that the developer using SDL would have read the documentation, or at least the comments in the headers... but we all know that doesn't always happen.

I don't think that the functions to wait would be dangerous, although the function is definitely unnecessary. The need to wait comes entirely from examples I've seen of the X11 clipboard. GTK provides functions to wait, too, so I wouldn't think it dangerous. You know more about X11 than I do, I'm sure, so you probably know better.

About having the clipboard data in the events... the drag'n'drop events are initiated by the user, the paste event is initiated by the programmer. It isn't as if these events pop up as soon as there is data on the clipboard or something is being dragged. I think it makes more sense to send the data right to the programmer in these cases, since at least 90% of the time they want it anyway.

That's the big thing with naming, I suppose.  Fill in the blank: Clip is to ____ as SDL_LockSurface is to Mutex.

Jonny D


On Sun, Jul 18, 2010 at 2:45 PM, Nathaniel J Fries wrote:

On Sun, Jul 18, 2010 at 4:45 PM, Nathaniel J Fries wrote:

Dangerous is maybe too strong a word here. I just don't want to have to worry about the effect of a wait function on my 3D animation. I also want to make the API simpler than the ones that X11 and the others provide. Frankly, I always disliked (OK, hated) the D&D and C&P API in X11.



I'm missing something here. I don't believe I suggested putting the data directly in the event. I  believe I mentioned putting a transaction ID in an event so that a single event and a simple API could be built that handled data coming in by either D&D or C&P. That doesn't mean I want to put the data in the event. That could be a really big event.

Bob Pendleton




--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:          
+ web: www.TheGrumpyProgrammer.com

So do I. It just doesn't seem logical to me.



You did. And then I stated why I think differently.

On Mon, Jul 19, 2010 at 8:51 AM, Nathaniel J Fries wrote:

OK, I've lost your point of view. It is just not in my head and deleted the first part of the discussion. Could you tell me your point of view again?

Sorry about that,

Bob Pendleton
 



--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:          
+ web: www.TheGrumpyProgrammer.com

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...

On Tue, Jul 13, 2010 at 11:22 PM, Nathaniel J Fries wrote:



--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I was not suggesting that at all.
When you paste from an X11 clipboard, you must request the contents from the selection.
The selection's contents are then sent to you through an X11 event.
This event is the "SDL_ClipEvent" in my original suggestion.
I thought I had made this clear in #3 of "What I've found..." at the beginning of my suggestion.

Following the same train of thought, the "SDL_WaitClipData" would simply wait until the requested event was received. Not until there was actually data on the clipboard.

And yes, storing images would be complicated. On Win32, you must convert it to a HBITMAP. On OS X, you have options. I don't know about how it's done on X11, but I imagine you could find out by looking at GIMP or Mozilla Firefox source code for X11.

On Tue, Jul 20, 2010 at 3:09 AM, Sam Lantinga wrote:

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




--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ web: www.TheGrumpyProgrammer.com
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hellos,

you might find the api for this illuminating
http://www.pygame.org/docs/ref/scrap.html

using mime types seems sensible.

cu.

On Tue, Jul 20, 2010 at 1:52 PM, Nathaniel J Fries wrote:

On, Wed Jul 21, 2010, Rene Dudfield wrote:


Yes it does. We already offered technical support to Sam, so I can just
repeat the offer here. The clipboard implementation for both, Win32 and
X11 based systems is fairly stable within pygame and can act as a nice
starting point to learn about the pitfalls (at least those, we ran
into) and how to get a basic implementation done.

Regards
Marcus

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Wed, Jul 21, 2010 at 1:35 AM, Bob Pendleton wrote:

Then perhaps, SDL_Clipboard should be based on GTK/QT instead?
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

No, I understood what you meant.  I was just (silently) referring to an API that I was trying to provide support for, which expected an asynchronous notification when the clipboard contents changed.  No worries.

On Tue, Jul 20, 2010 at 5:52 AM, Nathaniel J Fries wrote:



--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Yeah, I started working on a mime type based implementation and then
quickly ran into the fact that to support image copying and pasting I
would have to implement fairly complicated image converters for the
various platforms.

I quickly simplified it for SDL 1.3 release, but I structured the
functions such that there's no reason we couldn't add mime-type based
functions and extended clipboard support in the future. This could be
done now if someone is motivated to contribute it, or post release at
some point when someone really wants it.

See ya!

On Wed, Jul 21, 2010 at 11:48 AM, Marcus von Appen wrote:



--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Wed, Jul 21, 2010 at 7:50 PM, Jeremiah wrote:

On linux both GTK and QT run on top of X11.


--
+-----------------------------------------------------------
+ Bob Pendleton: writer and programmer
+ email:
+ web: www.TheGrumpyProgrammer.com
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I see, then.
If it were not for X11's design, I would agree that doing this would be a good idea. But certainly not a necessity for any application.


I would say to just worry about converting it to one image format supported by the system. Then you can use it together with applications not built to support these mime types, but do support whatever is available from the system. On Win32, this would be bitmaps (which should be fairly easy with an SDL_Surface). Don't know about other platforms.

Unfortunately on Mac OS X, the format in question is TGA, which require SDL_image support. :)

In any case, I've punted it post 1.3, unless someone wants to contribute working code sooner.

On Wed, Jul 21, 2010 at 10:27 PM, Nathaniel J Fries wrote:



--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

On 7/22/10, Sam Lantinga wrote:

What?! Did nobody actually look at my real, actually working
implementation for Mac and Windows which has been sitting around for
years? Mac uses TIFF as the native format, but once you get that,
there are other OS provided things that let me convert to BMP. I got
all this to integrate nicely with SDL proper. No SDL_image required.
It's all reasonably fast too.

Windows uses BMP. Unfortunately, there are a lot of missing
convenience things so I end up doing some hoop jumping creating proper
BMP headers, but I already did this nasty work for you. Again,
everything integrates nicely with SDL proper. No SDL_image required.
It seems reasonably fast too.

-Eric
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yup, I did look at it, but I wanted to add arbitrary clipboard format
support which your code doesn't have, and since I didn't have time to
go the full length, I left it at simple text support for now. If you
have time, I'd love to discuss complete support with you... after the
high priority 1.3 bugs you have are taken care of. :)

See ya!

On Fri, Jul 23, 2010 at 1:52 AM, Eric Wing wrote:



--
    -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

What he was saying is that doing so is not at all necessary or practical.

OS X and Windows have a specific format they want images in, TIFF and HBITMAP; respectively, and that's the only conversion that's worth any effort.
So, on OS X, just convert SDL_Surface to TIFF then back again.
On Win32, convert SDL_Surface to HBITMAP then back again.