GNOME Bugzilla – Bug 772281
Quartz backend: gtk_clipboard_get_selection not implemented
Last modified: 2017-07-19 03:29:58 UTC
While trying to compile the latest gtkmm 3.22.0 against gtk 3.22.1, I noticed a linking error: Undefined symbols for architecture x86_64: "_gtk_clipboard_get_selection", referenced from: Gtk::Clipboard::get_selection() const in clipboard.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Some investigation into this showed that gtk_clipboard_get_selection was never implemented in gtkclipboard-quartz.c, which is the file that gets compiled into libgtk3 when the quartz backend is requested.
Created attachment 339008 [details] [review] quartz: Implement gtk_clipboard_get_selection This function is trivial and can be copied from the X11 implementation.
gtk_clipboard_get_default() is also omitted from gtkclipboard-quartz.c. That omission is not noticed when gtkmm is build, because it's not wrapped in C++ code in gtkmm. Another omission, this one in gtkmm!
Thanks for pointing this out @Kjell. It's ironic that 3.22.x series is currently at 3.22.7 and this "trivial" function couldn't be easily added in the source.
(In reply to Partha from comment #3) > It's ironic that 3.22.x series is currently at 3.22.7 and this "trivial" > function couldn't be easily added in the source. It's not "ironic" at all. Just like Linux and Windows users volunteer their time to ensure GTK+ works on those two platforms, we rely on macOS users to actually help us making GTK+ work on their OS.
Review of attachment 339008 [details] [review]: Okay.
(In reply to Emmanuele Bassi (:ebassi) from comment #4) > (In reply to Partha from comment #3) > > > It's ironic that 3.22.x series is currently at 3.22.7 and this "trivial" > > function couldn't be easily added in the source. > > It's not "ironic" at all. Just like Linux and Windows users volunteer their > time to ensure GTK+ works on those two platforms, we rely on macOS users to > actually help us making GTK+ work on their OS. Yes, if the problem was known in gtk+. However, it shows up in making gtkmm.
It would be fine if someone with knowledge of macOS could also fix the missing gtk_clipboard_get_default() in gtkclipboard-quartz.c. Otherwise this story will repeat itself when we add Gtk::Clipboard::get_default() to gtkmm.
I'd suggest opening a gtkmm bug for that.
Comment on attachment 339008 [details] [review] quartz: Implement gtk_clipboard_get_selection Attachment 339008 [details] pushed as e338b45 - quartz: Implement gtk_clipboard_get_selection
Emmanuele, should I commit this patch to master as well? I haven't looked at how different the clipboard stuff looks on GTK 4...
(In reply to Philip Chimento from comment #8) > I'd suggest opening a gtkmm bug for that. For what? A gtkmm bug for the missing gtk_clipboard_get_default() in gtk+/gtk/ gtkclipboard-quartz.c?
Please ignore my comments 7 and 11. gtk_clipboard_get_default() is a specialization of gtk_clipboard_get_for_display(). The function in gtkmm, corresponding to gtk_clipboard_get_for_display(), declares the GdkAtom selection argument with default value GDK_SELECTION_CLIPBOARD, which makes it unnecessary to wrap gtk_clipboard_get_default() in C++ code in gtkmm. There is no reason to wrap gtk_clipboard_get_default() in gtkmm. If it's missing from gtkclipboard-quartz.c, it won't matter to gtkmm or users of gtkmm. But of course it might matter to users of gtk+. Sorry for these unnecessary comments.
gtk 3.22.16 fails to compile on macOS because of gtk_clipboard_get_default not being implemented: CCLD gtk3-icon-browser Undefined symbols for architecture x86_64: "_gtk_clipboard_get_default", referenced from: _copy_to_clipboard in iconbrowserwin.o ld: symbol(s) not found for architecture x86_64 Shall I open a new bug for this?
> Shall I open a new bug for this? Probably. I hadn't closed this one yet because I wasn't sure if the patch should be committed to master.
gtkclipboard.c hasn't changed significantly between 3.22 and master so I cherry-picked it over.