Care to elaborate what exactly this means? Unless you plan to provide a patch yourself, that's probably the only chance of getting it fixed, because assuming that people hacking on g-s-d know all there is to know about all aspects of the specs and technologies touched on is, well, wrong. ;-)

The way the clipboard works in X is that applications declare what formats ("targets") they are able to provide. When another application wants to paste, X asks the source application to produce the clipboard contents in the desired format. The idea is to avoid copying stuff around until somebody actually needs it.

If the program which owns the clipboard quits, it won't be around any more to produce the requested contents. This is where clipboard manager comes in. When a program quits while owning the clipboard, it copies the clipboard contents in each supported format to the clipboard manager. In Gnome, the clipboard manager is part of gnome-settings-daemon. I have no idea why.

The canonical name for strings on the clipboard these days is UTF8_STRING. Historical variants are TEXT, STRING and COMPOUND_TEXT. A program which calls gtk_clipboard_set_text automatically declares that it supports all 4 variations.

If we want older programs to be able to get TEXT, STRING or COMPOUND_TEXT, we have to send each format to the clipboard manager, although they will be almost identical. It seems to me that once the clipboard manager holds the UTF-8 representation, it would be easy for it produce TEXT, STRING or COMPOUND_STRING on the fly when requested, by using the standard mechanisms for clipboard text in GTK.

Hm, thanks. Do you know of a spec or something similar where the inner workings of the clipboard are detailed? Google isn't really helpful. Looking at the GTK source, it only seems to to support "down-casting" types. Ie. if you ask for UTF8, you may actually get COMPOUND, but if you asked for COMPOUND, you will never get UTF8. So from that, I don't know if generating the other representations is actually possible. I'd suspect GTK would do it in that case, though...

Ah, wait, you're actually saying g-s-d should do the same as gtk, right? I need to sleep.

Yes, that's what I'm saying. The code in g-s-d right now is very low level. so it would take some work to do what I suggested.

But here are some references:

The original reference is the Inter-Client Communication Conventions Manual - http://www.cl.cam.ac.uk/~mgk25/ucs/icccm.pdf
It's horrible, and inspired Keith Packard to write an essay named
"How to cut and paste in 1000 lines or more" - http://keithp.com/~keithp/talks/selection.ps

The two people who understand the lower layers of clipboard and selection best are probably Keith Packard and Owen Taylor.

There's a clipboard manager spec at freedesktop - http://www.freedesktop.org/wiki/ClipboardManager

A program interacts with the clipboard manager by calling gtk_clipboard_set_can_store
(http://library.gnome.org/devel/gtk/2.11/gtk-Clipboards.html#gtk-clipboard-set-can-store)
to tell the clipboard manager what formats it supports, and calling gtk_clipboard_store
(http://library.gnome.org/devel/gtk/2.11/gtk-Clipboards.html#gtk-clipboard-store)
when it is about to quit.

Perhaps the cliboard plugin can use gtk to set clipboard instead of calling X directly?

I discovered another problem (not with text but images). Steps to reproduce are simple, run the gnome screenshot application, take a screenshot, click the copy to clipboard button, close the screenshot application. Now the image is within the clipboard manager.

Try to paste inside OOo (or simply request the content of image/bmp). It will fail to paste the image. The four targets, image/bmp, tiff, x-bmp and x-MS-bmp seem to each contain garbage. If you paste in gimp (it will request image/png) it will work fine.

I like the suggestion to rewrite the daemon with GTK+ functions. I'm currently investigating this, I have a few test cases from which I should be able to build a manager (and not need all the XINCR protocol and complexity of the current manager). I will hopefully post it soon. However I will need a reviewer, all the selections stuff is new to me :-) Perhaps what I will propose can be made shorter, more efficient, ...

Created attachment 148057 [details] [review]
Rewrite with GTK+ functions

Here I go. Attached is a patch on top of gnome-settings-daemon.

What it changes:
- Drops all the X11 code (also xutils.c and list.c).
- Uses GtkClipboard and GtkSelectionData objects, respectively to listen to owner-changes and keep the targets in memory within the manager.
- Listens on the primary clipboard in addition to the default one (mouse/kb selections) which the current manager doesn't do. This makes it possible to select things in one application, close it, and continue to paste elsewhere. It does this by g_freeing/requesting the text content on changes.

Comments welcome :-)

Let's see if we can get Owen to comment...

Comment on attachment 148057 [details] [review]
Rewrite with GTK+ functions

I'm testing the manager currently in Xfce Clipman plugin and the primary clipboard handling code is BAD. I already changed it however I'll keep testing a little bit before updating this patch.

Created attachment 149583 [details] [review]
Rewrite with GTK+ functions tape #2 ;-)

Just like in comment 8 except that now it keeps a cached data from the primary clipboard in a none-aggressive way via a GSource at a quarter second interval that is reset as long as the mouse left button or shit key are hold before retrieving for real the text.

Created attachment 149584 [details] [review]
Rewrite with GTK+ functions tape #2 and a half

I forget to update the rest of the files (Makefile/xutils/list).

Taking for review

(In reply to comment #13)
> Taking for review

Great :)

I didn't update the patch in a while, but since the latest update there are at least three important patches. You can see them on the log below, starting on 2009-12-09 (after "Be less aggressive to store the primary clipboard").

  http://git.xfce.org/panel-plugins/xfce4-clipman-plugin/log/daemon

However, there is a bug related to Qt applications. When terminating a Qt application, it is hanging for 3-4 seconds before the process effectively quits and leaves the following message:

  QClipboard: Unable to receive an event from the clipboard manager in a reasonable time

Review of attachment 149584 [details] [review]:

This replaces an implementation of the ClipBoard manager according to:

 http://www.freedesktop.org/wiki/ClipboardManager

With a much cruder clipboard save mechanism based on the XFIXES clipboard notification mechanism.

 - Because it doesn't implement the ClipboardManager specification correctly, but still grabs the selection, it causes the hang noted for Qt applications
 - Because it is constantly saving the clipboard contents rather than only when requested at app exit, there are performance problems
 - There is no equivalent to SAVE_TARGETS here, so, e.g., if the GIMP was offering images on the clipboard it would be repeatedly saved in every format
 - Because it saves the selection any time it is released, it changes the behavior of the primary selection from the point of view of the user - GTK+ is strict that the primary selection is the *currently* selected text, not the last selected text. (Whether that's right or not is another debate, but if it should de be changed it should be changed in GTK+, it's not up to g-s-d to change that behavior.)
 - Always grabbing the selection when someone else drops it makes the race condition of stealing the selection away much much more likely. This could be mitigated using the right timestamps, but GtkClipboard removes the timestamps from the API to make it easier for applications to get things correct.

(In reply to comment #3)
> Hm, thanks. Do you know of a spec or something similar where the inner workings
> of the clipboard are detailed? Google isn't really helpful. Looking at the GTK
> source, it only seems to to support "down-casting" types. Ie. if you ask for
> UTF8, you may actually get COMPOUND, but if you asked for COMPOUND, you will
> never get UTF8. So from that, I don't know if generating the other
> representations is actually possible. I'd suspect GTK would do it in that case,
> though...

The clipboard is described in the X ICCCM (should be packaged as part of X docs for your distribution, or easily found with google.)

The way you'd implement Jon's suggestion is if the target list that you saved included UTF8_STRING then you'd augment the target list advertised with STRING/TEXT/COMPOUND_TEXT and do the conversion when the particular target was requested. gdk_utf8_to_compound_text_for_display() is exported for the tricky => compound text conversion, you might have to reimplement or cut-and-paste code from GDK for STRING, which is easier.

On the other hand, it's 2010, apps should just use UTF8_STRING; neither COMPOUND_TEXT nor mullets need to be preserved from the 1980s.

(In reply to comment #6)
> Perhaps the cliboard plugin can use gtk to set clipboard instead of calling X
> directly?

It's a little tricky because the X clipboard manager specification uses a feature of X selections that GTK+ doesn't support - the ability to pass data *from* the requestor to the selection owner. But I suspect you could break things into two parts:

 - Implement the manager selection in raw X along the lines of the current code
 - When saving the clipboard at application exit and re-exporting the clipboard after application exit, use GTK+ functionality.

Might need to use the lower level GtkSelection API rather than the higher level GtkClipboard API ... not sure without looking at the problem in detail.

Likely just easier to fix whatever bugs exist in the current code. GTK+ supports some complicated stuff like INCR transfers that this code doesn't, but they probably aren't *important* features. INCR transfers are meant to deal with X terminals where the X server might only have a few k of available storage.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/158.