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?


Klipper


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.

GSD-clipboard-manager


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

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

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

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. 

Conclusions

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.

Friday, May 21, 2010

Gearing up for GSoC: Clipboard Persistence for Ubuntu

GSoC & Ubuntu Clipboard Improvements

This summer I'll be tackling a Google Summer of Code assignment with Ubuntu keep clipboard contents from being lost when an application quits. You can check out my application here, developed with lots of input from my mentor Ted Gould and Ubuntu developers James Westby and David Bensimmon on IRC and the ubuntu-soc mailing list.

The problem: data loss on quit

Say you're writing an email in your word processor. If you copy it, paste it into your email client, and then close the word processor, you're golden. If you copy it, close the word processor, and try to paste, you're probably out of luck. It's an odd case, but when it happens it means loss of user data.

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.

The solution: save on exit

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. Unfortunately, there are very few applications that conform to this standard, and we believe that few developers are even aware of the problem. I hope to put together an online guide to fixing the problem while patching several popular Ubuntu programs myself.

A batch fix?

The adhoc approach of fixing a series of apps seems like it'll work, but we're looking for a more systematic way to knock out the problem in many places at once. Right now, we have a variety of clipboard history applications that provide clipboard persistence by keeping track of each copy performed. These panel apps get the job done, but they're probably too heavyweight for default inclusion in Ubuntu. A lighter weight solution might be to create a library that GTK+ application developers can use to easily fix this problem. I'll be comparing existing fixes to figure out whether this is a feasible approach.


Things to watch out for: performance problem, format support, upcoming GTK+ improvements

There are several things to keep in mind as I start investigating the problem.
  • I've seen reports that saving clipboard data can have a performance hit. I'll need to make sure I'm not imposing an unacceptable performance hit before I push out changes to a bunch of programs.
  • An application can broadcast that it can provide a picture the user has copied as a jpg to an image program and as a text link to an editor. I'll need to make sure I'm not imposing any regressions to multiple format support on any changes I make, and report on support status as I go.
  • There are some changes that might be coming down the pipeline to GTK+ this summer with the addition of a base application class. Ted mentioned that the sort of changes I'm proposing might be made easier then. All the more reason, then, to keep what I'm doing well documented so it can be easily reimplemented when there's a better place to put it.
Timeline (so far...)

Weeks one and two, May 24 - June 6, 2010

  1. Create an example program that exhibits the problem
  2. Fix the problem in the example program
  3. Put up a website that describes the problem and shows how to fix it using the example program
  4. Add a page of extra links and explanatory material for anyone who's researching the problem; have a section at the top for users who might just be googling the behaviour.
Weeks three and four, May 7 - 21, 2010
  1. Compile a list of existing patches that fix this problem and add them to the link page
  2. Read them to get an idea of how it's being fixed and where there are commonalities that could be factored out
  3. Fix the problem in one real application
  4. If it seems like a common library to make future fixes easier makes sense, put together a proposal for it
  5. Update documentation page so that it would have been useful to me in fixing the real app I tackled