Tuesday, June 8, 2010

Clipboard managers for Ubuntu

Patching is hard, let's go shopping! ...for clipboard managers

I had hoped to have at least one patch finished by now, along with general guidelines for implementing the fix in other applications. GTK+'s implementation of textbuffer already respects the ClipboardManager specification, making applications that use it fixed by default. Any other usage of custom built text areas in GTK+ seems to vary so wildly from application to application that a specimen fix makes little sense. I'm holding out hope that I can factor out commonalities in the fixes of GTK+ applications to build a library solution, but I haven't had much luck yet.

I've begun trying to patch vim, openoffice.org, and empathy to conform to the spec and with no success so far. As a change of pace, here's a survey of the clipboard management field as it stands. If we were to decide to fix this problem by bringing a more fully featured clipboard management application up to standard so it could be released as a part of Ubuntu main, it would free us (me!) from having to patch each application individually. A girl can dream, right?


Clipboard management isn't a problem in Kubuntu due to the tight integration of Klipper into KDE. It sits in the taskbar intercepting any and all copies performed in the system and making them available both after application quit and as a history in a panel app. Installing klipper in gnomic Ubuntu brings in a whole lot of kde libraries. On Ubuntu Lucid, I found it threw a warning, "QClipboard::setData: Cannot set X11 selection owner for PRIMARY," and failed to preserve clipboard contents after quit. The copied text was available in klipper's history, accessible by clicking on the panel icon.


Gnome Settings Daemon's clipboard manager runs in the background in Gnome systems including Ubuntu, taking care of preserving clipboard contents after quit by implementing the ClipboardManager specification. This only works for those applications kind enough to implement that same spec themselves.

One option to consider in this project is to integrate some of the functionality from the panel-based clipboard managers into GSD, keeping a record of each copy as it's performed without keeping a history or adding a panel applet. I've looked through the source and that looks quite doable, but the major consideration is whether it can be done without an inordinate impact on speed or reliability of GSD. Right now, it only registers copies when applications request it. Acting as a full clipboard manager would cause it to record many selections and copies that are never actually needed. We could perhaps reduce the load by supporting persistence only on the default (ctrl-V) register in conforming apps, at the expense of consistency.


Clipman is a component of Xfce and depends on many xfce libraries. It also has the same behaviour as Klipper when installed in regular old Gnome-based Ubuntu. What makes it interesting is that it includes gsd-clipboard-manager.c, the clipboard management plugin provided with gnome-settings-daemon, within its source. If we were to extend the functionality of gsd-clipboard-manager, this could be a good place to start.


Glipper was written as a Gnome-based alternative to Klipper. It installed oddly on my system, providing no executable in my path and no entry in gnome menu. Running the binary installed at /usr/lib/glipper/glipper provided no panel applet but did preserve clipboard contents after quit. It seems it's meant to run as a panel applet, so if I go down the route of working to bring it in as a default part of Ubuntu, I'll have to fix the install process. Users complain that it uses too much memory and is buggy. It's a python-based application that was last updated in 2007.


Parcellite is another Gnome clipboard panel applet, this time officially abandoned April 2010. It's written in C and I prefer its source to Glipper's mostly based on excellent commenting. It installed cleanly on my system, giving me an entry in "Add to panel" as Clipboard Manager. It preserved the clipboard after quit while sitting in my panel, collecting a history, and I wasn't able to reproduce the one bug I found reported about it, but I did find that its no-panel-applet daemon mode failed to preserve clipboard contents. 


Extending an alternate gsd-clipboard-manager that includes persistence seems like it would be worth doing if it could be done without noticeably impacting performance or reliability. GSD, however, is an essential system service that needs to be so speedy and reliable that I'm not sure it's feasible, at least for me.

It would be a good idea, I think, to make the Clipboard Manager panel applet (parcellite) available on a default install, without actually adding it to the default panel. That way we give users the option of fixing this bug in an easily discoverable sort of way without potentially running down slow systems or adding to panel clutter. I'll bring it up with my GSOC sponsor, Ted, and ask whether it would be appropriate to suggest it and spend time during my employment testing, fixing, and readying it for inclusion. That seems unlikely to happen at this late date, so I'll probably take up the maintenance and the cause once my time as a GSOC student wraps up.