Mechanism of Clipboard of Xwindow

Mechanism of clipboard of xwindow

Everything you could possibly want to know about X selections but were afraid to ask.

C++ Get string from Clipboard on Linux

Did you try to find not a code first but a program with an implementation ? I did it for you and found a lot of implementations which use direct X11 calls. I think the most valuable is this but also you may read this. Just find any program and look for the sources. Try to look on wikipedia what applications use x11 clipboard/selection system.

The following programs specifically operate on data transfer
mechanisms:

xcutsel transfers data from selections to cut buffers or vice versa

xclipboard, glipper (Gnome), parcellite (LXDE), and klipper (KDE) are
clipboard managers, maybe wmcliphist as well xcb shows the content of
the cut buffers and allows the user to manipulate them xselection,

xclip, xsel and xcopy are command line programs that copy data to or
from the X selection. xcopy has a verbosity option that helps debug X
selection issues. parcellite also has the ability to read from and
write to specific X selections from the command line.

synergy is a cross platform tool that allows you to share a clipboard across
multiple computers running multiple operating systems

xfce4-clipman-plugin is a "clipboard history plugin for the Xfce4
panel" and also a clipboard manager xtranslate looks up words in the
Xselection in a multi-lingual dictionary autocutsel syncs cut buffer
and selection buffer

Shortly, in theory, X11 has 2 "clipboards": actually a keyboard and for selections - the text you selected immediately can be pasted anywhere you want by pressing middle-mouse button while actual "keyboard" is made for main/default clipboard purposes as exchange by different kind of objects.

P.S. I'd not work with x11 anymore after my experience. Enjoy :)

How to copy to clipboard with X11?

Go read X Selections, Cut Buffers, and Kill Rings before anything else. X11 has a rather unique system that nobody else seems to have copied.

One oddity that is different from most other systems: if the program owning the selection (clipboard) goes away, so does the selection. So when your program says "I have a selection (which happens to be an image)" and then exits, nobody will be able to request a copy of that image from you. In order to be useful, the clipboard owner needs to stick around at least until another program takes the selection.

Still here? Here's a short program that does what you want, using PyGTK (because C is a pain).

#!/usr/bin/env python
import gtk
import sys

count = 0
def handle_owner_change(clipboard, event):
    global count
    print 'clipboard.owner-change(%r, %r)' % (clipboard, event)
    count += 1
    if count > 1:
        sys.exit(0)

image = gtk.gdk.pixbuf_new_from_file(sys.argv[1])
clipboard = gtk.clipboard_get()
clipboard.connect('owner-change', handle_owner_change)
clipboard.set_image(image)
clipboard.store()
gtk.main()

What happens under the hood:

• Gdk loads an image.
• Gtk claims ownership of the CLIPBOARD selection.
• Gtk requests that the CLIPBOARD_MANAGER copy and take the selection. (There might not be one running, so this might not happen.)
• When another program requests data from our selection, Gtk handles the conversion and transfer of data from the image to the target.
• The first OWNER_CHANGE event corresponds to us taking ownership; wait for the next one corresponding to us losing ownership, and exit.

If a clipboard manager is running, this program may exit immediately. Otherwise, it will wait until "cut/copy" is performed in another program.

Changing XWindow geometry

As @Andrey Sidorov said I have to call XFlush() before display closing. Now works.

cannot paste from clipboard in neovim nightly

Neovim doesn't have any code to access OS clipboard directly (or to process X Window events). Instead it delegates to external utilities/plugins. You're expected to execute :checkhealth command to see the current state. If you don't have any supported tool on your PATH then you'll not be able to access the clipboard.

As a shameless plug, I wrote plugin that consists of dynamic library providing direct access to clipboard. This is to avoid extra process creation for every copy/paste operation (btw. setting clipboard=unnamed[plus] is bad for more than just this single reason). However, the library must be built from source before use.

As of Wayland, its IPC mechanism is clearly different from X but at least in GNOME or KDE you may expect both selections being synchronized transparently. Otherwise you need specific utils to access Wayland clipboard, such as wl-copy/wl-paste.

xclip does not terminate when tracing it

XClip forks a child when launched without -verbose. The only difference with -verbose is that there is no child forked and the same original process handles ConvertSelection events.

Usually in X Window toolkits copy/paste is implemented via X Selections:

Selections are global server resources named by an atom and owned by a
particular client. The number of selections is not limited by the
protocol; as many selections as atoms may exist. Selections are
designed to provide the basis for building communication mechanisms
between clients. The official definition is found in the glosary of the
X Protocol:

"...an indirect property with dynamic type; that is,
rather than having the property stored in the server, it is maintained
by some client (the ‘‘owner’’).
A selection is global in nature and is
thought of as belonging to the user (although maintained by clients),
rather than as being private to a particular window subhierarchy or a
particular set of clients."

From the applications perspective,
selections provide a mechanism for transmitting information between X
clients. As X is a networking protocol, the existance of a separate
channel for data transmission between the various clients cannot be
assumed to exist. Selections are intended only for data transfer which
directly relates the the user-interface aspects of the application,
although there isn’t any enforcement of this policy.

Content of selection is stored in application itself and requested with
ConvertSelection event ("convert" here because there is a way for client
to ask for particular mimetype (or "view", or format) of selected data.
Conversion, again, happens in the application which owns selected buffer.

Because of this architecture, there is no way to "copy text to system
buffer and exit" - because you are a system buffer. XClip simulates "copy and exit"
by forking and daemonizing.

Copying to global clipboard does not work with Java in Ubuntu

I got the same problem with the application at my work and here's an article I've found that explain why and possible solutions. I hope it helps.

Why it happens

Clipboard persistence is a bug that affects many programs under Ubuntu and other X11-based operating systems. Fixing it is a Google Summer of Code 2010 project. Wikipedia has a good overview of the issue. If you want to fix as a user, you can install Parcellite or another clipboard manager. If you want to fix it as a programmer, you can modify your program to conform to the ClipboardManager specification.

X-Window wiki

Using gnome library you could call the store method on the clipboard and fix this. That's the only thing so far that seems to be worth trying. Also saw a similar thing for GTK but only in an Eclipse's bug.

---

Related Topics