To support having a number of different formats on the clipboard at the same time, the clipboard mechanism allows providing callbacks instead of the actual data. When you set the contents of the clipboard, you can either supply the data directly (via functions like Set_Text), or you can supply a callback to be called at a later time when the data is needed (via Set_With_Data or Set_With_Owner.) Providing a callback also avoids having to make copies of the data when it is not needed.
Set_With_Data and Set_With_Owner are quite similar; the choice between the two depends mostly on which is more convenient in a particular situation. The former is most useful when you want to have a blob of data with callbacks to convert it into the various data types that you advertise. When the clear_func you provided is called, you simply free the data blob. The latter is more useful when the contents of clipboard reflect the internal state of a GObject (As an example, for the PRIMARY clipboard, when an entry widget provides the clipboard's contents the contents are simply the text within the selected region.) If the contents change, the entry widget can call Set_With_Owner() to update the timestamp for clipboard ownership, without having to worry about clear_func being called.
Requesting the data from the clipboard is essentially asynchronous. If the contents of the clipboard are provided within the same process, then direct function call will be made to retrieve the data, but if they are provided by another process, then the data needs to be retrieved from the other process, which may take some time. To avoid blocking the user interface, the call to request the selection, Request_Contents takes a callback that will be called when the contents are received (or when the request fails.) If you don't want to deal with providing a separate callback, you can also use Wait_For_Contents. What this does is run the GLib main loop recursively waiting for the contents. This can simplify the code flow, but you still have to be aware that other callbacks in your program can be called while this recursive mainloop is running.
Along with the functions to get the clipboard contents as an arbitrary data chunk, there are also functions to retrieve it as text, Request_Text and Wait_For_Text. These functions take care of determining which formats are advertised by the clipboard provider, asking for the clipboard in the best available format and converting the results into the UTF-8 encoding. (The standard form for representing strings in GTK+.)
Return value: the appropriate clipboard object. If no clipboard already exists, a new one will be created. Once a clipboard object has been created, it is persistent for all time.
(Passing Gdk_None is the same as using Atom_Intern ("CLIPBOARD", False). See http://standards.freedesktop.org/clipboards-spec/ for a detailed discussion of the "CLIPBOARD" vs. "PRIMARY" selections under the X window system. On Win32 the Selection_Primary clipboard is essentially ignored.)
It's possible to have arbitrary named clipboards; if you do invent new clipboards, you should prefix the selection name with an underscore (because the ICCCM requires that nonstandard atoms are underscore-prefixed), and namespace it as well. For example, if your application called "Foo" has a special-purpose clipboard, you might call it "_FOO_SPECIAL_CLIPBOARD".
Selection is a Gdk_Atom which identifies the clipboard to use.
If no clipboard already exists, a new one will be created. Once clipboard object has been created, it is persistent for all time and cannot be freed.
Return "" if retrieving the selection data failed. (This could happen for various reasons, in particular if the clipboard was empty or if the contents of the clipboard could not be converted into text form)