There seems to be no freestanding crossplatform clipboard library for C.

Could this community perhaps be able to produce one?From what I can tell, there are gui libs that have clipboard features, and I heard something about SDL having something. But I'd like just a small lib that does nothing but clipboard stuff.

For starters all it needs is to copy and paste simple strings. That's by far the most used feature. And even if the library never does anything more it'd be a huge resource IMHO.

When I searched the forums I found an old thread about making a clipboard addon, it seemed for Allegro 4 and people said "I'll work on it tonight". What happened with that?

For a first contribution I've made an ugly hack implementation for Linux which uses the xclip terminal program. But it's better than nothing, and in the source of xclip perhaps someone can extract how to do it in C. I'm not that someone, that source is just horrible unless you're a real low level coder type.https://github.com/trezker/SWAG/blob/master/src/clipboard.cpp

---Febreze (and other air fresheners actually) is just below perfumes/colognes, and that's just below dead skunks in terms of smells that offend my nose.MiquelFire.red | +MeWindows 8 is a toned, stylish, polished professional athlete. But it’s wearing clown makeup, and that creates a serious image problem. ~PCWorld Article

When I use CTRL + V in Notepad I get "foobar". When I copy something in Windows and remove the clipboard_paste line the printf prints exactly what I coped. Dunno if it works on all versions of Windows, as I can only test on 7.

Heh, your function names are switched compared to mine.I felt it strange with the naming, since I'm performing the copy action in my application but I'm pasting into the clipboard, so what should the name of the function be?I guess we can use set and get like the windows functions.

Two more issues:Making a crossplatform library, I have no experience messing with this. Anyone else want to set up the build and code structure?

I think the library should be in C so the anti-C++ people can use it too.The issue that makes me a bit nervous about this is how to return the string, I've always been weak with string handling.

Here's what I came up with - ClipBoardTest.zipI based my versions on what Vanneto put up and I added in copying to and from the clipboard for bitmaps using Allegro 4. There's an executable test file in there for anyone who wants to try it. Bitmap copy/paste worked fine for me using paint.net, but I had some trouble with writing a string to the clipboard. When my program tried to read the string it came up with unknown characters. However, pasting my string into notepad worked. It also worked fine for reading things copied from notepad.

There's a cross platform structure in place, it's written in C, and all someone needs to do is add in code for Linux and Mac. It is based on Allegro 4 though. I will try to figure out why setting and then reading the clipboard string isn't completely working.

Edit - Hold on , trying to get the zip file uploaded, having trouble.Edit2 - Okay, the link is working now.

Edgar, I'd like to have this be a library that doesn't depend on Allegro.If we put in the ability to copy/paste image data, then the library should only handle the data without knowing anything about Allegro.

The crossplatform handling also uses ALLEGRO_PLATFORM defines, it should be using something else.

Edgar, I'd like to have this be a library that doesn't depend on Allegro.If we put in the ability to copy/paste image data, then the library should only handle the data without knowing anything about Allegro.

The crossplatform handling also uses ALLEGRO_PLATFORM defines, it should be using something else.

If you don't use allegro, that's fine with me, but you're going to be hard pressed to recreate a cross platform BITMAP structure if you want to copy/paste images.

Looks like a display is required for clipboard operations, at least xclip and SDL seems to use a display. I thought X11 selections wer ebound to the process, not the display... A little confusing.

It does seem to be troublesome to make a clipboard library without having it depend on more stuff.

Perhaps depending on Allegro can't easily be avoided. I'm not really planning on using this with anything other than Allegro anyway. So I don't really mind if it's an Allegro addon. Especially if you want to paste graphics then it would be a hassle to make it independent.

If it's only about handling strings then one could make a crossplatform xclip that works the same on all platforms and use that from C like I did.

As it seems now I think making an Allegro addon is the easiest solution. We can just steal code from SDL and adapt it.

I hope with "steal" you mean look at how they do it. Then later re-implement a similar idea. If you just copy&paste at any point it might violate the LGPL (unless the addon would be under LGPL as well)

If it's only about handling strings then one could make a crossplatform xclip that works the same on all platforms and use that from C like I did.

I rather surprised that the xclip developers wouldn't implement a high-level interface into a library and then use that from the application (I haven't checked that they didn't, but I don't get the impression that they did). A library is much more reusable than an application is. Then again, I guess in UNIX it isn't so expensive to spawn child processes. There's probably a better way to execute xclip where you could read/write directly from/to its standard streams instead of using a shell and the file system. That would eliminate our need for temporary files, at least.

I came up with another version for Linux based on the xclip system call you two were using. It's similar to yours except without error printing and without a temp file struct. It also allows getting arbitrary sizes of strings from the clipboard.

Peter - When you're reading from a pipe opened with popen, are the characters discarded from the pipe when they are read? I want to know the size of the information in the pipe so I only have to allocate memory for it once.

This was done primarily so that there was no little risk of overwriting a user's file. It's entirely possible for the user to have a .clipboard file or a temp_clipboard.txt file in the current working directory. Just assuming that you can overwrite it is bad practice. It would be one thing to take ownership of a dot file in the user's home folder, like $HOME/.libclipboard or something, but better yet is to just use existing library routines to create a temporary file.

I think it should be pretty well all C now. It's not very portable, obviously, and the interprocess communication isn't exactly bulletproof. It might be good to look into alternatives to 'system'. Perhaps we can read and write directly to xclip's streams.

Meh.

I wanted to tackle the temporary file thing first (it's a useful thing to learn).

Is anybody else patching Peter Wang's solution in or should I? Sounds like Edgar might be.

Append: Somebody else has this same library in GitHub already, but it's written in Ruby. It too is popening xclip though.