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 104827 - mouse selection doesn't use X selection unless SHIFTed
mouse selection doesn't use X selection unless SHIFTed
Status: RESOLVED NOTABUG
Product: vte
Classification: Core
Component: general
unspecified
Other other
: Normal normal
: ---
Assigned To: VTE Maintainers
Nalin Dahyabhai
Depends on:
Blocks:
 
 
Reported: 2003-01-30 17:06 UTC by galeon
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.1/2.2



Description galeon 2003-01-30 17:06:08 UTC
Using vte-0.10.8 with gnome-terminal 2.1.4 out of garnome-0.20.0, selecting text with the mouse doesn't place the selected text in the X selection (XA_PRIMARY) buffer unless one uses the shift key while selecting.  This is non-standard X behaviour.  If the current behaviour is intentional and kept, there should be a menu option (perhaps under profiles) for setting the standard X behaviour, instead (so that unshifted mouse selection uses the PRIMARY selection as well).

Either way, the behaviour should probably be documented somewhere (either in gnome-terminal or in vte).
Comment 1 Nalin Dahyabhai 2003-01-30 17:43:06 UTC
I can't reproduce this with 0.10.15.  Specifically, text I select in
gnome-terminal pastes into xterm using either the middle button or
shift+insert without problems.

If you're selecting text while running a mouse-aware application in
the terminal, then this is expected because click and drag events are
being sent to the application, and holding down the shift key
overrides that.
Comment 2 galeon 2003-01-30 17:47:48 UTC
Report retracted.  I was seeing strangeness in the selection mechanism, and used gcm (Gnome Clipboard Manager) to track it down, and that only showed the selection being updated with the SHIFT key down.  On retrospect, however, it is possible that the gcm, having been launced from the same terminal, was capturing the unshifted selection.  

I will continue to dig to figure out the (apparently unrelated) selection strangeness I experience sporadically.

Thanks.