After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 643391 - Allow key bindings to paste PRIMARY selection
Allow key bindings to paste PRIMARY selection
Product: gtk+
Classification: Platform
Component: .General
Other Linux
: Normal enhancement
: ---
Assigned To: gtk-bugs
: 720060 (view as bug list)
Depends on:
Reported: 2011-02-27 03:48 UTC by Andy Spencer
Modified: 2018-05-02 15:02 UTC
See Also:
GNOME target: ---
GNOME version: ---

Gtk 3 patch to add signal for pasting alternate selections (7.82 KB, patch)
2011-02-27 03:48 UTC, Andy Spencer
none Details | Review
Gtk 2 patch to add signal for pasting alternate selections (7.82 KB, patch)
2011-02-27 08:45 UTC, Andy Spencer
none Details | Review
Updated gtk3 patch. (7.35 KB, patch)
2015-11-04 00:05 UTC, Tom Prince
none Details | Review

Description Andy Spencer 2011-02-27 03:48:03 UTC
Created attachment 182026 [details] [review]
Gtk 3 patch to add signal for pasting alternate selections

I would like to have a way to insert the PRIMARY selection into a GtkEntry/GtkTextView using only the keyboard. I commonly use a laptop that only has two buttons, and trying to press them simultaneously can be difficult at times.

I wrote a patch that adds a "paste-selection" signal to GtkEntry and GtkTreeView. This is very similar to the "paste-clipboard" signal but takes a parameter for which selection to use. Then a key-binding can added to ~/.config/gtk-3.0/gtk.css to paste the selection.

I found this this related Chromium bug while searching for information:

For reference, I also sent a message to the mailing list:
Comment 1 Tobias Wolf 2011-02-27 08:02:51 UTC
+1000. Please get this in.

Shift-Ins is something else than middle-mouse because you don’t have to move the mouse cursor from where you copied to where you want to paste. It’s more friendly for keyboard nav users and it stands in the glorious tradition of X11.

Andy, what about GTK 2? Is an analogous patch possible too?
Comment 2 Andy Spencer 2011-02-27 08:45:30 UTC
Created attachment 182029 [details] [review]
Gtk 2 patch to add signal for pasting alternate selections

Actually I originally wrote it for 2.22.1 since that's what I'm running by default. I'm not sure if there are plans to add features to Gtk+ 2.0 though, but here's the patch anyway. You'll need to add the bindings to ~/.gtkrc-2.0 instead of the css file for 3.0.

Also available from git:
  git:// paste-selection-3.0
  git:// paste-selection-2.24.1
Comment 3 Tobias Wolf 2011-02-27 10:56:19 UTC
So, I compiled gtk 2.24 with your patch, but I can’t figure out how to specify the binding. Can you give me an example?

This is what I have now:

binding "gtk-binding-text" {
    bind "<shift>Insert" { "paste-selection" () }
class "GtkEntry" binding "gtk-binding-text"
class "GtkTextView" binding "gtk-binding-text"
Comment 4 Andy Spencer 2011-02-27 18:19:29 UTC
You'll need to give it a parameter for the selection to use ("primary", "secondary", or "clipboard"). For example, to mimic gnome-terminal's paste behavior:

  binding "gtk-binding-text" {
      bind "<shift>Insert"       { "paste-selection" ("primary") }
      bind "<ctrl><shift>Insert" { "paste-selection" ("clipboard") }
      bind "<ctrl><shift>v"      { "paste-selection" ("clipboard") }
  class "GtkEntry"    binding "gtk-binding-text"
  class "GtkTextView" binding "gtk-binding-text"
Comment 5 Tobias Wolf 2011-02-27 21:01:48 UTC
Sweet. It works just as intended.
Comment 6 Raphaël 2011-05-22 15:27:28 UTC
the patch applied against 2.22.1 on my gentoo box

the patch works as intended for zenity but sadly not for firefox 4, in my case:

(firefox:7354): Gtk-CRITICAL **: IA__gtk_widget_get_clipboard: assertion `gtk_widget_has_screen (widget)' failed

(firefox:7354): Gtk-CRITICAL **: IA__gtk_clipboard_request_text: assertion `clipboard != NULL' failed

However it'll be an awesome improvement in my daily use of firefox (ctrl-k / shirt-insert) !
Comment 7 Raphaël 2011-08-05 17:43:17 UTC
Same Gtk warnings with patched Gtk 2.24.4 + Firefox 5 (but works fine with zenity).
It's a must-have for Gtk 3 !
Comment 8 Raphaël 2013-03-30 18:52:58 UTC
any hope for this issue ?
Comment 9 Tobias Getzner 2014-03-31 11:57:51 UTC
It would be nice to have a keybinding to paste the primary selection. However, one caveat is that Shift+Ins is a CUA-standard for inserting. Enough apps still adhere to this, and keyboards with dedicated copy/insert-keys send this combo upon pressing insert; so it would be a nuisance to not be able to access the clipboard at all in such contexts if the semantics of shift-ins were to change (since there is no mouse-fallback for the clipboard).

Given that the XDG spec. ( considers the clipboard to be primary, it would be consistent to leave shift-ins bound to pasting from the clipboard, but to add a secondary binding ctrl-shift-ins which would paste the primary selection instead.
Comment 10 Nuno J. Silva 2014-09-21 13:56:57 UTC
Despite this being in some list of keybindings (be it CUA or freedesktop), several applications (including Firefox, if I'm not mistaken), used to paste from the primary selection on shift-insert. So I'm not sure if the consistency argument is the best one here. This push for CUA-bindings has actually *broken* consistency in X Windows, even if it made GTK+ consistent with MS-DOS applications.

Right now, it seems that there is no way to paste the primary selection using the keyboard in GTK+ applications, while some applications use exclusively the primary selection.

It is also a nuisance not to be able to access the primary selection at all, except that, unlike the clipboard selection, where programs usually bind control-c and control-v as well, there seem to be no other keyboard bindings currently available to paste the primary selection.

If GTK+ prefers to default to the clipboard selection instead of the primary selection, then perhaps a sensible solution would be a setting to toggle between both using some GTK+ configuration file. This if GTK+/GNOME are willing to allow a couple, mostly hidden, configurable settings.
Comment 11 Mikael Magnusson 2014-10-11 18:32:15 UTC
+      if (g_str_equal(which, "primary"))
+	gtk_entry_paste (entry, GDK_SELECTION_PRIMARY);
+      else if (g_str_equal(which, "secondary"))
+	gtk_entry_paste (entry, GDK_SELECTION_PRIMARY);

these both say PRIMARY (same mistake in both gtk2 and gtk3 patches).

Has someone tried this with a more recent version of firefox, does it still not work there?
Comment 12 Tom Prince 2015-11-04 00:05:09 UTC
Created attachment 314775 [details] [review]
Updated gtk3 patch.

I've fixed the incorrect instance of `SECONDARY` as well as updated the reserved bits being replaced.
Comment 13 Tom Prince 2015-11-04 00:11:26 UTC
> However, one caveat is that Shift+Ins is a CUA-standard for inserting.

I don't think anybody is asking for the default to be changed, just the ability to change the defaults for those of us whose muscle memory trips them up umpteen times a day.

> Has someone tried this with a more recent version of firefox, does it still not work there?

This won't work as-is with firefox, unfortunately, as firefox uses a hidden widget and intercepts the signals. The errors that one gets are because the widget isn't actually attached to X, and so can't access the clipboard. Since this is a new signal, firefox doesn't know to hook into this. Once this lands, though, firefox could be taught to intercept this signal as well. (
Comment 14 Tom Prince 2015-11-04 03:05:26 UTC
There is a proof of concept patch for firefox that builds on this at
Comment 15 Matthias Clasen 2016-03-06 02:17:36 UTC
*** Bug 720060 has been marked as a duplicate of this bug. ***
Comment 16 GNOME Infrastructure Team 2018-05-02 15:02:23 UTC
-- 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: