why klipper is bad
With grief I learned that the latest KDE is still using the awful hack called Klipper, a clipboard daemon that works in the most stupid way possible. If you want to know why it sucks, I suggest you try a KDE system where Klipper is running (AFAIK that’s the default with KDE 3.4). Then start GIMP and create a large image, for example by picking the A3 (300 dpi) template. Then try to duplicate the background layer using Ctrl-C, Ctril-V. This is a common operation and it is usually very fast because GIMP duplicates the layer using copy-on-write on the layer’s tiles. Starting with GIMP 2.2, GIMP also announces the content of it’s internal clipboard to the systemwide clipboard. Basically we tell the X server that we have image data to offer in a variety of formats. An application that wants to paste this image data can then pick the preferred format from this list and request the actual data. Only then does GIMP create and provide the requested image. For a large image this can take a while but that is not avoidable and usually acceptable (but will improve somewhat with GTK+ 2.8, see bug #305340).
Now the problem that Klipper tries to address is that if the application that provides the clipboard content exits, that you can’t paste the image any longer. In order to achieve that, Klipper requests each image that is being announced on the clipboard. So what you end up with if you are trying to duplicate a layer using Copy and Paste is a GIMP application that is busy for quite a while providing a PNG image of the layer. This image is then being transferred over the X server to Klipper that itself needs to allocate memory to hold the image (and optionally even decodes it to provide a preview). But most of the time that is not what you want to happen. Almost all of the time Klipper only gets into your way.
Fortunately the problem that Klipper tries to address can also be fixed in a sane fashion. As I wrote earlier, the development branch of GIMP actively stores the content of the clipboard on exit. So there is absolutely no point in requesting the clipboard whenever GIMP announces that is has something to paste. The clipboard manager should only do that when it is being asked to take over the clipboard content because the application is going to quit.
It looks as if GNOME 2.12 will have clipboard manager functionality integrated into gnome-settings-daemon. It implements the Free Desktop Clipboard Manager Specification. Let’s hope that the KDE apps and Klipper adopt this standard as well. It’s easy and it will make our desktops suck less.
June 18th, 2005 at 3:42 am
Do you know that Klipper not only stores the current entry but keeps a history which is a main feature? This specification likely only works with a “one-item” clipboard manager.
June 18th, 2005 at 11:43 am
maybe you can work together with aaron to make Free Desktop Clipboard Manager Specification a standard…
http://aseigo.blogspot.com/2005/06/simple-suggestions-for-fdo-and.html
June 18th, 2005 at 2:28 pm
I admit that the clipboard management specification leaves things to desire. But the current behaviour of Klipper is just plain broken. If people need a history and previews of the clipboard content, then the clipboard spec should be extended to deal with that. Unconditionally claiming the clipboard is not an option.
July 16th, 2005 at 12:54 am
Klipper is configurable. Click RMB on its icon, choose “Configure klipper”, choose “Advanced”, add gimp’s WM_CLASS to the list of ignored apps. That’s all. To learn what WM_CLASS gimp uses, use the standard X wminfo app.
July 16th, 2005 at 12:57 am
Although I didn’t test it and I realize it might not work.
July 18th, 2005 at 2:55 pm
I think there is 2 points in the case – 1st: you cry before you trying to learn (klipper is one of those magical things what makes KDE much better than windows) and 2nd: as it mentioned, it seems that klipper is broken in kde 3.4 – it doesn’t ignore applications which are said to ignore. Try older version or wait fix or disable klipper when working with gimp.
Greetings, U
July 19th, 2005 at 12:46 am
What really needs to be done is to extend the proposed clipboard spec to include ways to obtain the functionality of Klipper without the problems outlined here. There should be a way to ask an application for a preview w/o having to retrieve the full-size version of the clipboard content. And applications could also provide a history. This does however need a well-designed spec and a lot of cooperation between desktop and application developers to actually get it implemented and widely used.
November 6th, 2005 at 6:28 am
i’m just glad we have copy/paste functionality between applications at all. if you guys are new the linux world it has taken years to get copy/paste between applications to work and it’s still not perfect. it’s a been a while since copy/paste of text has been supported but applications actually supporting it are only even half suporting it and not that well as can seen. When will kde/linux in general be ready for the desktop user? i don’t know. but i’m doing everything i can to make it happen. testing it with non-technical users is the only way to make this happen and this information needs to go back into the products to improve them.
February 2nd, 2006 at 1:03 pm
See Lubos Lunak answer at:
http://www.kdedevelopers.org/node/1787
March 1st, 2006 at 12:49 am
I prefer KDE as my desktop for the simple fact that it has klipper. I use it ALL the time. I can’t say I’ve ever used it to move anything but text data, but for that its great. If it weren’t for klipper I might actually consider using gnome…bleh. =)
March 6th, 2006 at 10:58 am
When I moved from Windows to Linux Kipper was my saving grace! I use multiuple cut and paste extremely heavily, and as far as I can work out Klipper is the ONLY clipboard tool for Linux at all.
This amazes me. If those OSS development nutters can get it together to build software which controls atomic reactors and run server farms like Google, why can’t we have a simple tool which can keep mutiple things on the clipboard. Windows have had this for over a decade… there are hundreds of excellent Win clipboard apps availble.
Whassup with that?
March 6th, 2006 at 8:01 pm
Amazing how misunderstood my complaints are. There is of course nothing wrong with having a clipboard manager and of course I see the need for this functionality. The point is just that some particular implementation details in Klipper are broken beyond repair. Beyond repair because there’s no chance to fix them without changing the underlying protocols. We urgently need to redesign how the clipboard works on the X desktop. The current protocol is just too simple to implement all the requested features in a sane manner.
March 23rd, 2006 at 4:49 pm
I guess I understand the gripe, but to be honest, it seems like a really specific issue is being used to argue against what is, imho, a great little app. I just recently moved from windows to Linux. I use clipmate in windows, and frankly, although its sluggish, its pretty sweet. When people sit next to me while I’m doing something its like they’re watching a concert pianist for the first time. The problem is I’m so used to having that clipboard history that I was contemplating moving back to windows. Klipper stopped me from considering that. Problems or no problems. I can turn it off for gimp if need be. Having said that, if the clipboard functionality needs fixing, I’m all for that too. But klipper is sweet.
By the way, I use Gnome. I was pretty pissed when I saw it was a kde app. However, it installs and runs fine in gnome (ubuntu 5.10).
March 25th, 2006 at 6:04 am
The WM_CLASS trick doesn’t seem to work on my FC5 system. I tried to add “gimp” or “Gimp” but Klipper still won’t ignore Gimp. The WM_CLASS found by xprop is “gimp”, “Gimp” (yes there are two values).
September 15th, 2006 at 6:59 am
I have to agre with Marc. klipper is one of my favourite apps. Can’t live without it.
Stuck on a Windows box at my new job and missing Klipper soo much [and other great features of Linux that Windows lacks]. A search for a decent clipboard for Windows brought me here…