GNOME Bugzilla – Bug 644379
Drag and drop on dual screen does not work
Last modified: 2017-07-30 16:03:14 UTC
I have a Dual screen (separate X screen) computer. When I try to drag and drop a data from a screen to another, the drop occurs in the source screen. Because my application works with 2 screens with completely different properties, I could not use the drag and drop for my application.
Thanks for taking the time to report this bug. However, you are using version 2.18 that is too old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use. By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME. Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME.
I've track this bug and fall into _gdk_make_event (in gdkwindow.c:9889 for GTK+2.24.1) function that seems to make a dirty copy of event. In my case the private field "screen" of structure GdkEvent is lost. I want to know the purpose of this function why don't you use gdk_event_copy ? The code has not moved since 2.18. So I think the bug always exists in the latest GTK+ 2. Also note that GTK+2.18 is the version used by the latest RedHat (v.6) for professional use.
Created attachment 183063 [details] [review] Patch to copy the screen of source event (if any) patch on _gdk_make_event function This patch just copies the screen of event_in_queue (if both exists) to the newly created event. I quickly test this patch with gtk-demo (clipboard) it solves the bug. The version of source file was GTK+2.18.9. (see patch header) Since I do not understand the meaning of _gdk_make_event function I have done minimum change for my case but I think it would be better to use gdk_event_copy rather than copy field manually (because private field will not be copied) when event_in_queue exists.
Well, the previous patch goes to XErrors : my test was only with stocks id image, this test works. But when I tried to drag and drop a text when the preview drag icon changed screen the apps crashes with an XError. Both error are send when the drag and drop try to create the "fallback" DnD icon set_icon_stock_pixbuf in gtk_drag_get_icon. But there is 2 cases : - if the drag widget screen is the default screen : the app crash occurs in the XShapeGetRectangles function - if the drag widget screen is not the default screen : the app crash occurs in the _gdk_windowing_get_shape_for_mask (the mask is get from the default screen) Am I wrong or GTK+ was never tested with this kind of configuration (separate X screen).
> Am I wrong or GTK+ was never tested with this kind of configuration (separate X > screen). Multi-screen setups are pretty rare these days. Normally, people use their monitors combined into a single protocol screen via xinerama/xrandr. Anyway, thanks for your analysis so far !
Created attachment 183128 [details] correct XError BadMatch when a DnD with preview is made between 2 screens This correction is not THE optimal one. But at least it works.Now the effect of DnD when changing screen disable the preview and set the GTK_STOCK_DND icon.
Created attachment 183129 [details] [review] correct XError BadMatch when a DnD with preview is made between 2 screens The correction is miminal. When the Drag preview window changes screen, the default GTK_STOCK_DND is set.
My analysis is that when creating a shape window, the mask (Pixmap) is not set to the same screen than the Window. So X server send the BadMatch (SigABRT), because the documentation of shape extension is inexistant, I will stop here my investigation.
Is this still an issue?
(In reply to Emmanuele Bassi (:ebassi) from comment #9) > Is this still an issue? Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!