clipboard

[Havoc Pennington <hp redhat com>]

Hi,

Been reading gtkselection.c, gtkeditable.c, ICCCM, Java docs, and 
Qt docs.

Right now we don't have a very nice clipboard API - the API is
reasonable if you are implementing cut/paste within a GtkWidget
subclass (see GtkEditable code), but otherwise the fact that X
implements this as a funky property-setting event-sending protocol is
just confusing.

A nice abstraction that works on at least Java's X implementation:

  http://java.sun.com/products/jdk/1.3/docs/api/index.html
  (see java.awt.datatransfer.Clipboard)

Qt has basically the same thing, with the notable addition 
of convenience functions for cheesy cases (get/set text, get/set image):

  http://www.troll.no/qt/qclipboard.html

I'm assuming that both of these work by creating a GtkInvisible-style
proxy window global to the app, but I don't know.

Possible nice way to wrap the API:

 - GtkSelectionData is crufty.
   Something more like java.awt.datatransfer.Transferable 
   or QMimeSource, with clean accessor functions and maybe
   convenience wrappers for text/images/monikers, would be nicer. 

   Example of the problem with GtkSelectionData (from DND but 
   you get the idea):

    if ((data->length >= 0) && (data->format == 8))
    {
      g_print ("Received \"%s\" in trashcan\n", (gchar *)data->data);
      gtk_drag_finish (context, TRUE, FALSE, time);
      return;
    }

   Compare to:
       if (gtk_transferdata_is_string(data))
          g_print("Received: %s\n",
                  gtk_transferdata_get_string(data));

   or something to that effect.

 - A GtkClipboard object that didn't contain atoms, widgets, 
   and windows in its API would really simplify things. This 
   would be like the Java and Qt clipboard objects, which have
   really trivial APIs:
     set_contents(transferdata)
     get_contents()
     clear()
     "contents_changed" signal 

This should be totally simple to implement, since it's just a wrapper
interface hiding GtkSelection - I'll do it if it sounds good.

Havoc