clipboard
Philip brings up the X11 clipboard problems again. There seems to be a lot of talk about this recently. Probably caused by the fact that the clipboard starts to become used. Not long ago, the only thing that would get passed between X11 applications by means of copy and paste was plain text. Recently more and more applications start to support passing images and other content over the clipboard. In GIMP 2.2 we introduced the ability to copy and paste image data between GIMP and other applications.
As Philip outlines, one of the problems of the X11 clipboard is that if you copy an image, quit GIMP, start Inkscape and attempt to paste it, that it doesn’t work. It doesn’t work because the owner of the clipboard only announces the availability of the data. Only if the data is actually requested, it is delivered to the X server to be passed to the requesting client. If the application that copies the data exits, there is no way to still paste the content. Sure, if you know about this limitation, you can easily work around it. But it should just work, shouldn’t it? There have been several attempts at fixing this problem. Fixing the problem involves creating a third party in the game. A daemon that takes care of preserving the clipboard in case the owner dies. This daemon is often referred to as a clipboard manager.
Most implementations I have seen so far make the mistake of always requesting any clipboard content that is being announced. But if I copy a layer in GIMP, most of the time I want to paste it in the very same GIMP application again. There is absolutely no point in having a clipboard manager that asks GIMP to provide this data in all possible formats that GIMP offers it in. And there are quite a few them. This can easily take the application down for several minutes, keeping it busy to provide the data as PNG, JPEG, BMP…
But there’s hope. I would love being able to point you to a copy of the clipboard-manager spec that used to be available at freedesktop.org. The idea behind this spec is to provide means for an application to mark the data formats that should be made persistent and to actively ask the clipboard manager to retrieve the data. GTK+ added the necessary API with version 2.6. We are using this in the HEAD branch of GIMP and, together with a clipboard manager that implements the spec, it just works. Copy in GIMP, close it, open the latest Gnumeric (1.5.1) and paste the image there. Brilliant!
May 25th, 2005 at 9:12 am
hmmm, but i can’t try it now. cvsanon has 24 h delay
May 25th, 2005 at 11:17 am
Support for the clipboard manager is in CVS for several weeks already. Even anoncvs should have picked up that change by now.
May 25th, 2005 at 2:37 pm
The SAVE_TARGETS Atom
Hey Sven,
A few days ago I tested the clipboard-manager of Anders. Regretfully, however, it’s using gtk. It would be better if a desktop-neutral solution was build. The freedesktop concept really doesn’t need ten different solutions for one…
June 18th, 2005 at 12:19 am
[...] 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 o [...]
January 13th, 2006 at 11:00 pm
[...] ith a GtkTreeView for AsyncWorker » The SAVE_TARGETS Atom Hey Sven, A few days ago I tested the clipboard-manager of Anders. Regretfully, however [...]
May 10th, 2006 at 2:30 am
How about the clipboard that creates a kind of pointer to the gimp’s clipboard and the feature be apart of X11 instead of some gtk loaded environmental service, then when the program exits, it warns you of data in the clip board (familiar any one?), and if the program unexpectedly exits then when the paste (or uncut method) of the clipboard is executed and the pointer leads to freed memory or something unfamilar to whats not suppose to be there, it catches the exception and gives some kind of message. people seldom try to paste what they didn’t copy, if they left something in the gimp clipboard when it crashed they wouldn’t try to paste it anyway, so when they do, the message wouldn’t get annoying.
May 10th, 2006 at 11:06 am
dacres, what you suggest is impossible to implement since you cannot share pointers between applications. And even if you would implement this using shared memory, the problem you are trying to address is already nicely solved by the clipboard-manager in recent versions of gnome-session.