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 759607 - gtkdnd-quartz: fix gtk_drag_begin_internal
gtkdnd-quartz: fix gtk_drag_begin_internal
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
3.19.x
Other Mac OS
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2015-12-17 18:58 UTC by Christoph Reiter (lazka)
Modified: 2016-01-01 14:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gtkdnd-quartz: fix gtk_drag_begin_internal (3.60 KB, patch)
2015-12-17 18:58 UTC, Christoph Reiter (lazka)
committed Details | Review

Description Christoph Reiter (lazka) 2015-12-17 18:58:38 UTC
Created attachment 317586 [details] [review]
gtkdnd-quartz: fix gtk_drag_begin_internal

gtk_drag_begin_internal was changed to take a GtkImageDefinition
instead of a GtkIconHelper. This adjusts the quartz variant
accordingly.
Comment 1 Matthias Clasen 2015-12-17 19:04:16 UTC
It would be really nice if we could use this occasion to investigate what it would take to merge the quartz stuff back into gtkdnd.c
Comment 2 Christoph Reiter (lazka) 2015-12-18 14:41:36 UTC
With my very limited knowledge some thoughts after looking over the
implementation:

* The current implementation is split between gtkdnd-quartz.c and
  GdkQuartzNSWindow.c (implements NSDraggingSource and NSDraggingDestination),
  gdkdnd-quartz is not implemented/unused.
* Afaics the native DnD APIs are used for displaying the drag image, every
  image gets converted to a NSImage and passed to the native APIs.
  GdkQuartzNSWindow receives status updates on the drag and synthesizes
  events. As a result only images are supported atm, no widgets/windows.

From what I see the preferred method for drag icons handling is now to have a
GtkWindow on the GTK+ side and let the backend provide a GdkWindow which
handles the position/drawing etc.

Two possible solutions for killing gtkdnd-quartz:

1) Keep using the native APIs (NSImage), provide a dummy GdkWindow, make a
   snapshot of its initial state and use that as drag icon in the backend
2) Provide a real windows for dragging and use a transparent one pixel
   NSImage as drag image. Keep the position of both in sync using the native
   dragging events. I'm not sure if this works when dragging things to
   external apps as the drag window might be a problem? This will probably
   break the fade out/back animation as the drag image is immutable (and in
   this case transparent) and I think the animation is handled by the native
   APIs.
Comment 3 Matthias Clasen 2015-12-19 22:50:43 UTC
I think 1) would be easier and more in line with the other backends.
Comment 4 Partha 2015-12-23 14:56:21 UTC
This is broken again? 3.19.1 compiles fine but 3.19.4 does not?
Comment 5 Partha 2015-12-23 14:59:25 UTC
Sorry, forgot to add the error:

gtkdnd-quartz.c:1181:1: error: conflicting types for 'gtk_drag_begin_internal'
gtk_drag_begin_internal (GtkWidget         *widget,
^
./gtkdndprivate.h:30:25: note: previous declaration is here
GdkDragContext *        gtk_drag_begin_internal         (GtkWidget              *widget,
                        ^
Comment 6 Christoph Reiter (lazka) 2015-12-23 15:00:06 UTC
The patch/fix isn't pushed yet.
Comment 7 Christoph Reiter (lazka) 2015-12-23 17:52:23 UTC
(In reply to Matthias Clasen from comment #3)
> I think 1) would be easier and more in line with the other backends.

Sounds good. I've opened bug 759816 to track this.
Comment 8 Christoph Reiter (lazka) 2016-01-01 14:08:53 UTC
Comment on attachment 317586 [details] [review]
gtkdnd-quartz: fix gtk_drag_begin_internal

Pushed this now to unbreak the build. I hope that's ok.