GNOME Bugzilla – Bug 672358
Introduce a GdkClipboard abstraction to replace the various GtkClipboard implementations
Last modified: 2013-08-28 17:21:24 UTC
I'm mostly going to repeat what I said here: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/954352/comments/15 Someone created gtk+ packages for Ubuntu Precise with both the wayland and x11 backends enabled. It doesn't work. X doesn't start without putting export CLUTTER_BACKEND=x11 export GDK_BACKEND=x11 in ~/.xsessionrc Once that's done, X starts, but isn't usable. Best example, I think, is if you try to run gnome-terminal with those previous to environment variables set, you get: Gdk-CRITICAL **: gdk_wayland_device_get_selection_type_atoms_libgtk_only: assertion `GDK_IS_DEVICE_CORE (gdk_device)' failed
This is because of the way the clipboard support is implemented (ala quartz) with a separate file patched in that implements the GtkClipboard API but doesn't use the GDK abstraction. The correct solution is to add some kind of GdkClipboard / GdkDnD abstraction to push this through - that would then allow the multiple backends to coexist.
Wouldn't it be enough to make gtk_clipboard_get_for_display smart enough to return the right clipboard implementation for the display at hand ?
(In reply to comment #2) > Wouldn't it be enough to make gtk_clipboard_get_for_display smart enough to > return the right clipboard implementation for the display at hand ? we'd still need to implement a separate GtkClipboardImplementation class, with a vtable composed of all the methods of the class, and then make an implementation for x11, wayland, win32, and quartz and select at run time depending on the display manager type.
right, of course
sounds like a good 3.6 goal
For 3.4 do we want to: 1. Pull out the copy and paste implementation 2. Make configure bail out if you try to build both Wayland and X backend 3. Only build the Wayland GtkClipboard implementation iff X backend is disabled 4. Do nothing
apparently, the Quartz backend follows 4: if you build both the x11 and the quartz backend on Mac OS you'll only get the quartz-based clipboard variant. so, at this point, doing nothing and waiting for a proper abstracted implementation in 3.6 (with a Wayland implementation tracking 1.0) may just be the better option.
Created attachment 210329 [details] [review] build: Don't use Wayland GtkClipboard implementation if also building for X This patch is for "#3" above. I've tested it with both X11 and Wayland builds. I know it's close to freeze time so I won't be offended if it doesn't land.
Lets hold this for 3.4.1 at this point, I want to stick to crash fixes between now and next week
Review of attachment 210329 [details] [review]: Looks fine for 3.4.1 as a quick fix to improve the situation. For 3.6, we should look at doing the clipboard abstraction
Comment on attachment 210329 [details] [review] build: Don't use Wayland GtkClipboard implementation if also building for X Patch committed but keeping bug open for underlying issue.
retitling for clarity
first part of this work has been pushed
Created attachment 252982 [details] [review] remaining selection fixes I pushed a number of straightforward fixes for wayland clipboard handling, and this patch is the last few fixes required to get basic copy and paste working. The patch is essentially a couple of heuristics to either filter out the legacy X atom content types or rewrite UTF8_STRING to text/plain;charset=utf-8. The patch works fine, but I wasn't sure if we wanted to do this at a higher level instead. We could make gtk_clipboard_request_text() just ask for text/plain;charset=utf-8, and then let the X backend expand that to the UTF8_STRING, COMPOUND_TEXT and STRING targets as well.
Kristian, I think we should land this as it currently stands and look to do the change in the higher level in the next cycle.
Yeah, the fix by Kristian makes sense. We need a clipboard abstraction that gets rid of GtkTargetEntry or mime types because mime types don't work for at least text. But I suspect they're equally broken for images, HTML, and all the other kinds of data you want to exchange between display server and apps. I originally wanted to avoid having per-backend and per-data-type serialization functionality, but I'm more and more convinced that is the right approach, at least internally.
Also, the whole GtkClipboard API is a mess because it is severly underdefined and doesn't tell you what it does. For example, I'm not sure if Wayland or X11 get this one right: "When the results of the result are later received the supplied callback will be called." And that's only from the docs of the most important function.
Comment on attachment 252982 [details] [review] remaining selection fixes Kristian has pushed these changes as 459e6a3
Are we good to close this bug now?
There is more work to do, but it is no longer wayland-specific, so we could move the bug from wayland to gdk.
(In reply to comment #18) > (From update of attachment 252982 [details] [review]) > Kristian has pushed these changes as 459e6a3 Only just pushed it now: commit 921e81ebc94ac1d706bb54436fd870eb0d47f091 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Wed Aug 28 10:18:36 2013 -0700 wayland: Don't try to fetch ICCCM text content types Go straight for text/plain;charset=utf-8 and ignore fallback attempts for increasingly obscure text types. commit 73eea248d4cd01f486a5dacfac35b4067f6c1650 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Wed Aug 28 10:17:10 2013 -0700 wayland: Filter out ICCCM content types when setting clipboard contents commit 630c52c308e84cb0a5aa0856c667aac4f543f4c2 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Wed Aug 28 10:14:42 2013 -0700 wayland: Fix missing return value in gtk_clipboard_wayland_set_contents() Closing this one now.
Ha, Benjamin pushed it, all good then. I did like the "increasingly obscure" commit message though.