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 603169 - Most users would expect Shift+Insert to act on CLIPBOARD instead of PRIMARY
Most users would expect Shift+Insert to act on CLIPBOARD instead of PRIMARY
Status: RESOLVED OBSOLETE
Product: vte
Classification: Core
Component: general
0.20.x
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks: 123844
 
 
Reported: 2009-11-27 17:59 UTC by Tony Houghton
Modified: 2021-06-10 14:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Tony Houghton 2009-11-27 17:59:51 UTC 
This is in response to #123844, but I was asked not to comment on closed bugs and I can't see a way to reopen it.

This has been brought up in roxterm's tracker too
<https://sourceforge.net/tracker/?func=detail&atid=698428&aid=2780123&group_id=124080>
and I too would suggest CLIPBOARD. The standard the keystroke comes from
appears to be based on desktops with an explicit copy action, not traditional X's primary clipboard.

If there's a strong case for both sides, would you consider an option in VTE's
API, something like vte_set_shift_insert_clipboard(...)? This would be tidier
for applications (gnome-terminal, roxterm etc) than having to add a key event
handler.
Comment 1 GNOME Infrastructure Team 2021-06-10 14:19:16 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: https://gitlab.gnome.org/GNOME/vte/-/issues/1746.