Hey, David & Kevin, It does sound like you're describing parcellite's behaviour. Parcellite was designed as a low-footprint application, so the fact that it caches only from apps that request it using the ClipboardManager specification is probably by design. It's no longer maintained as of this winter, but we could revive it and patch it, perhaps modeling changes after how the problem is dealt with in Klipper (KDE's equivalent) as a GSOC project. The issue of conforming to <a href="http://freedesktop.org">freedesktop.org</a> ClipboardManager specifications is also valuable, I think, but there's definitely more than one way to tackle this. My only worry with that is that it's included as a part of gnome-settings-daemon. I don't know who decides what gets included, but I'm wary of slowing down performance of a code app without consulting those who decided to include it when it had very light resource usage. Maybe any changes could be enabled/disabled with a flag? Relevant links: Parcellite: <a href="http://parcellite.sourceforge.net/">http://parcellite.sourceforge.net/</a> Klipper - part of kdebase, find source & communication channels at: <a href="http://kde.org/community/getinvolved/development/">http://kde.org/community/getinvolved/development/</a> Klipper docs <a href="http://docs.kde.org/stable/en/kdebase-workspace/klipper/index.html">http://docs.kde.org/stable/en/kdebase-workspace/klipper/index.html</a> Thanks! -Sarah