Daily Archives: 25 May, 2005

Phillip: the majority of applications have no cut and paste code in them — they rely on the cut and paste behaviour of the standard widgets. Since the standard widgets like GtkEntry in GTK 2.6 mark their selections as being savable (in fact, any code that calls gtk_clipboard_set_text() will have its selection marked as savable). Most of the remaining cases are ones where you’d want to be selective in what gets saved (e.g. selecting cell ranges in Gnumeric, or regions of images in Gimp), so need to be handled specially anyway.

So if you have a desktop running with GTK 2.6 and have a clipboard manager running, saving of clipboard contents will just work. With similar changes to Qt, Mozilla and OpenOffice you cover pretty much everything the user will come into contact with. For extra points, patch Xt and Xaw, and you’ll get most of the ancient X programs as well.

As for the use of GTK in Anders’ sample clipboard manager, I’m not sure what the problem is here — the important thing is the protocol, which is not GTK specific. I would expect that most desktop environments will provide their own clipboard manager, possibly integrated into some existing desktop component such as gnome-settings-daemon. Then again, they could just use a standalone clipboard manager like Anders’ one if they want.

Lastly, you brought up console programs again. I see this as a red herring for the following reasons:

• There needs to be a single synchronisation point that states who owns the clipboard. This is to ensure that there is at most one owner of the clipboard, and allows paste requests get the right data.
• If you want to interoperate with the X clipboard, you’ll need to allow X to control the clipboard ownership. So if some app is connected to your clipboard daemon, the daemon will need to assert ownership of the X clipboard on behalf of the application.
• If the console app is going to have to be modified to talk to a clipboard server, what is the benefit of making the program depend on your clipboard daemon instead of bypassing it and using Xlib? Conversely, if the console app doesn’t want to talk to an X server, what makes you think it will want to talk to some other clipboard daemon?

The remainder of your points seem to either fall under the subject of standardisation of clipboard formats (not directly related to clipboard managers), or things that can be experimented with using the clipboard manager spec.