[Wayland-bugs] [Bug 758396] Clipboard of terminal get out of sync with the main clipboard on Wayland

[gnome-terminal (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=758396

--- Comment #4 from Christian Persch <chpe at gnome.org> ---
In this case here, Shift-Ctrl-V just does:

  clipboard = gtk_widget_get_clipboard (..., GDK_SELECTION_CLIPBOARD);
  gtk_clipboard_request_targets (clipboard, ...)

and on receiving the targets:

if (gtk_targets_include_uri (targets, n_targets)) {
    gtk_clipboard_request_uris (clipboard, ....)
  } else /* if (gtk_targets_include_text (targets, n_targets)) */ {
    vte_terminal_paste_clipboard (VTE_TERMINAL (data->screen));
  }

where vte_terminal_paste_clipboard is just gtk_clipboard_request_text().

So if the 'previously used text' is received by these request functions, I
really don't see how that could be any fault of g-t/vte.

Comment 0 doesn't state from which programme the clipboard data originated; if
it's g-t (via Shift-Ctrl-C) then that's just from
gtk_clipboard_set_with_owner() for the GDK_SELECTION_CLIPBOARD GdkClipboard ,
text/plain target and the selected text as data.


Also note that vte has ZERO code that depends on the gdk backend, and g-t only
has a couple such checks (WM checks (gdk_x11_screen_supports_net_wm_hint(),
"window-manager-changed" signal handling) [I'll just remove these now since
they're obsolete], setting of an environment variable in the child process on
the X backend, and using X directly to get a fallback startup timestamp).  THAT
is the basis for my assessment that a bug that occurs on wayland but not on X,
is a priori unlikely to be a g-t/vte bug. So I'm not just 'blindly' moving bugs
around!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20151123/079543d0/attachment.html>