Shift-Insert shortcut fails intermittently about roxterm HOT 9 CLOSED

When you say "only in ROXTerm" do you mean you can't reproduce this bug in gnome-terminal? These keybindings seem to be built into VTE so I think the bug must be in that.

Original comment by: realh

from roxterm.

(I inadvertently filed this when not logged in, so I didn't see your question from a few months back until now.)

...do you mean you can't reproduce this bug in gnome-terminal?

I haven't tried.

These keybindings seem to be built into VTE so I think the bug must be in that.

OK, I'll try a few experiments with gnome-terminal and file a ticket against VTE if I can reproduce it.

If I get that far, I'll post a link here to the upstream VTE ticket.

Original comment by: tmetro

from roxterm.

...do you mean you can't reproduce this bug in gnome-terminal?

I ran across this bug today, and switched over to gnome-terminal and found that the same clipboard buffer would refuse to paste there too. Using the menu option worked, as it did in ROXterm.

It also appears that one source for populating the clipboard that leads to this problem is the Vinagre VNC client. If I copy text on the remote system, it fails to paste via the shortcut in VTE terminals. (There always seem to be bugs relating to the clipboard when it comes to VNC clients on X.)

The behavior seems to suggest that there are two clipboard buffers, and Vinagre is only populating one of them. I've also observed in some case that when I use the keyboard accelerator to paste, instead of nothing happening, I'll get the contents of the clipboard prior to the last copy operation. Again suggesting there are two buffers.

I'll see about posting a ticket against VTE, seeing as this doesn't seem to be within ROXterm's control.

Original comment by: tmetro

from roxterm.

Yes, there are two clipboards in GTK on X. The traditional X clipboard (where anything selected is immediately available to paste with the middle button) is GTK's "PRIMARY" clipboard. Windows-style Copy & paste menu items etc generally use GTK's "default"/"CLIPBOARD". I think Qt/KDE does the same because it's an XDG spec.

Original comment by: realh

from roxterm.

Yes, there are two clipboards in GTK on X.

Thanks for the clarification. I thought I had ran across that before...

The traditional X clipboard...is GTK's "PRIMARY" clipboard.

So it would appear that shift-insert is bound to pasting from PRIMARY and Vinagre is not populating PRIMARY, while other X apps. are, as a side effect of the selection process. With Vinagre no selection is happening within X, so it is probably behaving correctly.

I found this VTE bug (from 2006):
http://bugzilla.gnome.org/show_bug.cgi?id=331152

that exactly describes the problem, which was marked a duplicate of this bug (from 2003):
http://bugzilla.gnome.org/show_bug.cgi?id=123844

which starts out talking about a related problem and then morphs into a long back-and-forth about which buffer should be used for shift-insert, and having the alternate buffer accessible from ctrl-shift-insert.

The behavior they ended up with doesn't match my expectations, and having not used an X desktop as my main desktop during the past decade, I wouldn't find the PRIMARY buffer useful, but the ticket suggests they don't want to change this behavior.

The thread does mention the idea that the emulator application can override the VTE keybindings. I'd suggest implementing a permanent override in ROXterm, but I don't know if the existing shift-insert behavior actually fits the expectations of a long-term X user. (I know they won't for anyone migrating to X from another platform. Shift-insert is a CUA standard for paste dating back to the early 90's if not earlier.)

So might it be possible to accomplish this with a custom keyboard accelerator setting?

I went into the configuration manager, copied the default keyboard accelerators, selected it, and anticipated that a "Properties" button would appear to permit editing the accelerators, but it didn't. Not implemented yet? I presume there is a text file somewhere I can edit? If so, then I just need to figure out what default key binding is used to paste CLIPBOARD.

Original comment by: tmetro

from roxterm.

See also:
http://bugzilla.gnome.org/show_bug.cgi?id=119125

for a bit more relevant discussion. I didn't look at the patch in that ticket, but the discussion seems to imply the problem was "fixed" to have the behavior opposite of what I observed.

Original comment by: tmetro

from roxterm.

I guess they must have felt they had good reason to make it use PRIMARY, so in that case I'm likely to get complaints if I hardwire the reverse behaviour. I've commented on http://bugzilla.gnome.org/show_bug.cgi?id=123844, perhaps you'd like to do the same.

I went into the configuration manager, copied the default keyboard
accelerators, selected it, and anticipated that a "Properties" button
would appear to permit editing the accelerators, but it didn't. Not
implemented yet? I presume there is a text file somewhere I can edit?
If so, then I just need to figure out what default key binding is used
to paste CLIPBOARD.

To edit ROXTerm's keyboard shortcuts hover over a menu item and press the key you want to use. Some desktops don't let you do that until you tick a box in the global config, for instance in GNOME's Appearance capplet. Despite that I think this is a much better way of editing shortcuts than some separate klunky dialog.

Original comment by: realh

from roxterm.

I've commented on [VTE bug #123844], perhaps you'd like to
do the same.

I originally refrained from commenting, as it was a closed ticket, appeared to be a decided matter, and I didn't have anything new to add, but the suggestion you posted made sense, so I've added a comment supporting that.

To edit ROXTerm's keyboard shortcuts hover over a menu item and press the
key you want to use.

Yes, that worked. And that effectively works around the problem as far as I'm concerned, so you can close this ticket. (Maybe add it to an FAQ somewhere?)

...is a much better way of editing shortcuts...

Yes, it works well, providing you know it is available.

Seeing as there is a setting in GNOME to enable editing shortcuts, does that mean this technique is desktop-specific? Or does it adhere to some freedesktop.org standard?

Original comment by: tmetro

from roxterm.

The method for changing shortcuts is in the manual and I recently made it more prominent. Other GTK-based desktops (ROX and xfce4 at least) support it, I don't know about KDE.

Original comment by: realh

from roxterm.