Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

[SOLVED] Clipboard confusion

New to Debian (Or Linux in general)? Ask your questions here!
Post Reply
Message
Author
jrv
Posts: 38
Joined: 2012-05-03 12:20

[SOLVED] Clipboard confusion

#1 Post by jrv »

I am running xfce on debian (probably "Test", but I am not at home to check), and I wanted to take some screenshots of windows and paste them into gimp. I used "xfce4-screenshooter -w -c". In gimp (current version) I used "create, from clipboard." gimp would throw up an error, "There is no image data in the clipboard to paste." I looked in clipman, and the image was there (displayed as a thumbnail) at the top of the list, in addition to other items. After flailing about for a while, I discovered empirically that if I took the screenshot, opened clipman and clicked on the image in the clipboard stack, then used "create, from clipboard" in gimp, everything works.

Before this everything I put in the clipboard and pasted has been text, and text has always worked without getting clipman involved. Is this difference because it was image data? Do I have some setting wrong? Is this due to the fact that the program doing the copying (xfce4-screenshooter) exits before the paste? When I was researching this, I found references to linux having multiple clipboards. Is my confusion related to that? I basically want to understand what happened. And if there is some change that would eliminate having to open clipman, I would appreciate knowing that too. Thanks.

JR
Last edited by jrv on 2014-11-06 17:58, edited 1 time in total.

jrv
Posts: 38
Joined: 2012-05-03 12:20

Re: Clipboard confusion

#2 Post by jrv »

After some more research, this is what I think is true:

1) Clipboards are not a function of the OS in Linux
2) X-Windows has clipboard functionality, called "X Window selection" (http://en.wikipedia.org/wiki/X_Window_selection). There are two (really three, but the third isn't used that often) clipboard-like selection storages, "CLIPBOARD" and "PRIMARY".
3) Since I believe the program that generated the data (xfce4-screenshooter) terminates after the depositing the image data, the image data has to be sent into some other process to make it available for pasting. This other process is a clipboard manager, in this case clipman.

From this I believe the (mis-?)behavior I observed is resident in clipman. It somehow sees that xfce4-screenshooter has clipboard data available and copies it into its process, making it available there (as well as in the original source?). For some reason it does not make this image data the "current" clipboard data, even if the other . Here I am a bit fuzzy on who gimp would ask to find the "current" clipboard data. It would seem likely that it would have to be the X Windows server, but I don't know for sure. Clicking in clipman makes the image data the "current" clipboard data.

It is possible that I have two clipboard managers running (perhaps clipman and xclipboard?).

It is possible that clipman stores the data under one of the two selection storages (CLIPBOARD and PRIMARY), and gimp asks for the data on the other. Clicking in clipman synchronizes the two storages.

Does anyone know if any of these are more likely than the other? Is there a tool that can be used to inspect the current state of the X Windows selection data?

JR

jrv
Posts: 38
Joined: 2012-05-03 12:20

Re: Clipboard confusion

#3 Post by jrv »

After some more research and some code skimming, I am satisfied I know what is happening and how to correct it. As it turns out X Windows supports as many copy/paste selections as applications would care to create. Most of these copy/paste selections are named, however. The destination has to know the "name" of the selection to get access to it. This is only useful when applications are designed to work together.

X Windows also has three "well-known names," PRIMARY, SECONDARY and CLIPBOARD. (The well-known name “SECONDARY” is not used very often, so I will consider only the two well-known names “PRIMARY” and “CLIPBOARD.”) Applications that are not designed to work together can register selections with these well-known names. X Windows does not take the data itself. The source application acquires “ownership” of the well-known clipboard, but it does not transfer the data yet. X Windows relies on the source application to provide the data when the destination application asks. If the source application terminates the data registered in the clipboard is no longer available.

By custom the two well-known names are used at different times (see this article: http://www.jwz.org/doc/x-cut-and-paste.html). The “PRIMARY” clipboard is used for the currently selected item in an application. The “CLIPBOARD” is used when a user explicitly selects “cut” or “copy” (for example by the menu or by a keyboard shortcut such as control-c).

A quick skim of the code reveals that xfce4-screenshooter writes the image to the well-known name “CLIPBOARD”. It then terminates, and how the image data remains available is the next part of the story.

I’m sure many people felt that it would be an improvement if data were not lost to the clipboard when the source application terminated. Another opportunity for improvement was that it would be nice if the clipboard could store previous items that had been stored and not just the most recent two (one for each well-known name). To solve these problems programs known as a clipboard managers were created. Xfce has a clipboard manager called “clipman.” Gnome has one called “Glipper” and KDE has one called “Klipper.” There are others available.

Clipboard manager programs run all the time, waiting for a change of selection in a well-known clipboard. When such an event occurs, the clipboard manager program will request the data from the owning application and copy that data into its own memory. It will then register the selection in the same clipboard it copied from. When a paste occurs in a destination application, the data comes from the clipboard manager and not from the source application. This means the source application can terminate before the destination application requests a paste, and the paste will still work. It also means that multiple items can be stored for each well-known name by the clipboard manager. Of course there has to be a way to change the current selection since only one item can be “current.” In clipman one clicks on its icon in the taskbar, which brings up a list of items, then clicks on one of the items. clipman makes that item the current one.

As I said, there are two well-known names, and xfce4-screenshooter copies to the once called “CLIPBOARD.” The clipboard manager clipman brings the data over to itself almost immediately. I’m guessing it makes the data available under the same well-known name, but I have not looked at the code. So now the question is, why can’t gimp find the image data to paste. And here I have again guessed that gimp looks in the well-known selection named “PRIMARY,” not in the well-known selection named “CLIPBOARD.” clipman has the image data available in “CLIPBOARD,” but gimp is looking in “PRIMARY.” By the selection conventions I mentioned above, when I open clipman and click on the image data (selecting it), clipman makes the data available in “PRIMARY” too. And now gimp is able to paste the data.

So this is the source of my confusion: there are two clipboards in X Windows, and if two applications disagree on which clipboard to use, it looks like clipboards don’t work. As you might expect, this was noticed a long time ago, and there is a “fix” for it. clipman can be set to synchronize the two clipboards so that when data is made available in one, it is also available in the other. Right-click on clipman, properties, general. There should be a checkbox for “sync selections” or similar. I’m sure other clipboard managers offer the same functionality too.

reinob
Posts: 1189
Joined: 2014-06-30 11:42
Has thanked: 97 times
Been thanked: 47 times

Re: Clipboard confusion

#4 Post by reinob »

@jrv,

Thanks a lot for the explanation!

HacimLlih
Posts: 1
Joined: 2019-07-30 14:34

Re: [SOLVED] Clipboard confusion

#5 Post by HacimLlih »

Ditto the appreciation of the shared research! ;]]

Post Reply