Clipboard persistence is a bug that affects many programs under Ubuntu and other X11-based operating systems. Fixing it is a Google Summer of Code 2010 project. Wikipedia has a good overview of the issue. If you want to fix as a user, you can install Parcellite or another clipboard manager. If you want to fix it as a programmer, you can modify your program to conform to the ClipboardManager specification.
The problem: data loss on quit
If you copy something from an affected application and then close it, you'll have an empty clipboard.
Workaround: Clipboard Managers
If you want to fix this problem on your machine, you can install a clipboard manager that should solve it. I recommend Parcellite. It's available in the universe repositories, and you can install it with:
sudo apt-get install parcellite
When you restart your computer or run it manually from Programs>Accessories>Parcellite, you'll have a panel applet that quietly saves a history of all your copies. You won't have to go look at the history to resurrect your copied text. Copy, quit, paste should just work.
Parcellite is also available for other distributions.
Similar programs include
- Klipper, a part of KDE
- Glipper, an alternative for the Gnome environment
- Clipman, for XFCE
Why does this happen?
The problem happens because Xorg takes a conservative approach to copying. It copies only a reference to the original data when the user performs a select or copy. It doesn't go and retrieve the actual data from the source program until the user requests a paste. It saves a lot of unneeded transfer of data this way, at the expense of having no way of retrieving data from a closed program that hasn't saved its clipboard somewhere else.
How to test it
- Maintaining the selection buffer after quit is optional. Some developers think that since the selection is not visible after quit, the clipboard buffer should not be available either. Try both buffer (select and ctrl-C) before you report a bug.
- Many applications are fixed for simpler situations like entry boxes in preference dialogs but broken for main text input fields. Make sure you're clear about which aspect of the user interface you're testing.
Some applications treat rightclick->copy differently from ctrl-C copy. Most notably, a terminal emulator such as gnome-terminal will intercept mouse clicks but not ctrl-C. This means that all console applications run in gnome-terminal are fixed for mouse copy/paste, no matter what their behaviour for system clipboard access through the keyboard. Make sure you test them both.
How to fix it: the ClipboardManager spec
Freedesktop's ClipboardManager specification comes to the rescue. Gnome settings daemon, the component of Ubuntu that handles all copying and pasting by default, conforms by allowing applications to explicitly request to save their clipboard contents in a safe place. Applications conform by requesting a save before they exit. Everything gets squared away before a quit and we don't lose any data.
Pure Gnome applications that use standard features like TextViews are automatically supported.
Applications that use GTK+ features can provide persistence by
setting set_can_store on clipboard contents whenever they gain ownership of the clipboard
saving clipboard contents on quit with gtk_clipboard_store
Xlib provides a variety of selection management functions that can be used to store clipboard data. http://michael.toren.net/mirrors/doc/X-copy+paste.txt's a great introduction to Xlib clipboard functions, but be aware that the document is twelve years old and written before the existence of the ClipboardManager specification.
The state of things
There are very few applications that conform to the ClipboardManager standard, and we believe that few developers are even aware of the problem. It has notably been fixed, however, in Firefox, most Gnome applications, Evolution, and Pidgin.
There is currently (2010) a Summer of Code project for Ubuntu devoted to fixing the problem. Please contact SarahStrong for updates.
GIMP: Confirmed for text, works for graphics
Here's a list of applications that are working but with no evidence that someone explicitly worked on a fix. They may never have needed fixing on their own because the developers involved were aware of the ClipboardManager specification, or they may be fixed by merit of using GTK+ elements such as TextBuffers that take care of clipboard management without extra developer involvement.
- Gnome terminal
- Gedit - note that the initial implementation of GSD-clipboard-manager was designed to target gedit
- Getting Things Gnome