+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?

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://lug.rose-hulman.edu/~spenceal/gtk+ paste-selection-3.0
  git://lug.rose-hulman.edu/~spenceal/gtk+ paste-selection-2.24.1
  http://lug.rose-hulman.edu/git/?p=~spenceal/gtk%2B

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"

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"

Sweet. It works just as intended.

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) !

Same Gtk warnings with patched Gtk 2.24.4 + Firefox 5 (but works fine with zenity).
It's a must-have for Gtk 3 !

any hope for this issue ?

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. (http://www.freedesktop.org/wiki/Specifications/ClipboardsWiki/) 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.

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.

+      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?

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.

> 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. (https://github.com/mozilla/gecko-dev/blob/07ed19e582faf40f5f72567169db62452f6c6dc9/widget/gtk/NativeKeyBindings.cpp#L265-L266)

There is a proof of concept patch for firefox that builds on this at https://bugzilla.mozilla.org/show_bug.cgi?id=1070518

*** Bug 720060 has been marked as a duplicate of this bug. ***

-- 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/gtk/issues/352.