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 334467 - Paste text at current cursor position with mouse
Paste text at current cursor position with mouse
Status: RESOLVED DUPLICATE of bug 81880
Product: gtk+
Classification: Platform
Component: Widget: Other
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2006-03-13 19:44 UTC by Yeti
Modified: 2017-09-14 10:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proof of concept patch (2.69 KB, patch)
2006-03-13 21:03 UTC, Yeti
none Details | Review

Description Yeti 2006-03-13 19:44:54 UTC
Current paste-with-middle-button behaviour is to either

(a) move the cursor to the place where mouse click occured and paste the text there -- this is what GtkEntry does

(b) paste the text there the click occured, but keep cursor position unchanged -- this is what GtkTextView does

While not very consistent, both paste the text at the mouse position.  This makes cumbersome to paste text at the current cursor position (which is a common case) because one has to precisely locate that position with pointer again.  Some people prefer the behaviour `middle-click anywhere, text is pasted at cursor position' (similar to, e.g., terminal emulators and gvim).

The attached patch adds a new Gtk+ setting "carefree-pointer-paste" (probably to be renamed to something more reasonable) that is FALSE by default; when it is set to TRUE it makes GtkEntry and GtkTextView always paste text at current cursor position and never move it by paste.
Comment 1 Yeti 2006-03-13 19:49:31 UTC
Attachment creation seems to be b0rken, so I'll attach the patch later...
Comment 2 Owen Taylor 2006-03-13 20:10:50 UTC
So how do you see this option being set? I don't think GTK+ behavior
can be made a set of unrelated toggles ... things like this interact with
each other in subtle ways. And even if it was a legitimate matter of
user preference, adding something that is only going to be set by
0.1% who know to edit their gtkrc doesn't make sense.

Not to mention the whole question of carry-over ... do you really
want this option when firefox doesn't pick it up? When your friends
computer behaves different? When you have to set it in the gtkrc
every time you do a new install. (You'll give up eventually...)

To first approximation, if something is right, if something isn't
right it isn't right.

(Not to over-rant, this is more inspired by a recent request on
gtk-devel-list)
Comment 3 Yeti 2006-03-13 21:00:58 UTC
Of course I think the current behaviour is wrong and should be fixed, but I'm used new options generally have greater chance to be accepted than unconditional changes of behaviour, so I pragmatically proposed it as an option.

I'm aware it can possibly interact with other things in subtle ways.  However, it should not to, it is in fact a simplification of what the widgets have to do now (if it was not optional, that is).

Now to the rethorical questions...

Ad Firefox.  Opera won't pick it up either.  I know Firefox does use Gtk+ unlike Opera, but Firefox uses it only to create its idiosyncratic non-gtk-feeling GUI, so do not care about it any more than about non-Gtk+ apps.

Ad configs.  No problem, I'm used to carry all my configs with me to all machines, gtkrc being among them for a long time, and I automated that (a bit more in the spirit of Unix than to give up).  It's a piece of cake especially when compared to compilation of patched Gtk+ on each machine.

Ad friends.  They will be the first to switch this on (and each one has his environment optimized for him far beyond the point where it is still usable for other people anyway).

I will gladly attach a three-line patch that simply changes the behaviour to the `right' one if it has a greater chance to get in.
Comment 4 Yeti 2006-03-13 21:03:15 UTC
Created attachment 61205 [details] [review]
proof of  concept patch
Comment 5 Daniel Boles 2017-09-14 10:20:38 UTC
I'm going to presume that a new setting is unlikely to get in, and that therefore this boils down to a dupe of Bug 81880 asking for TextView to behave like Entry by moving the cursor position.

*** This bug has been marked as a duplicate of bug 81880 ***