GNOME Bugzilla – Bug 56349
DnD code doesn't notice new windows
Last modified: 2011-02-04 16:09:06 UTC
If a new window appears during a drag, the DnD code usually (but not always) fails to notice. Try the following: - Load a program that accepts drops. - Start a drag, but don't move the mouse far. - When the window appears, move over it. - The pointer doesn't show a '+' and the drag fails. If you stop the drag and start again, it works. Rather more serious: If there is a window underneath the new window, the drop appears to work, but goes to that window! This is particularly bad with filers supporting mac-style 'spring opening' directories, since the file often goes in the wrong place.
Could you check to see if the problem is simply the problem that is observed in GTK+'s 'testdnd' test, where an enter is not sent until the mouse is moved? (drag over the word 'Popup'.) I don't know of any other problems. This is fixable, though it might require some changes to the gtk<->gdk interface. (Supporting spring-loaded folders was a consideration in writing the code in GDK - it is supposed to track new windows appearing on the screen - see gdk_window_cache_filter ())
No, that isn't the problem (although that's also annoying ;-). You can move the mouse around as much as you like and it just acts as if the new window isn't there. Putting some g_prints in gdk_window_cache_filter shows that it gets the map event for the new window, and the child structure has correct x,y,width,height (same as reported by xwininfo -frame).
Ah ha!!! GList *above_node = g_hash_table_lookup (cache->child_hash, GUINT_TO_POINTER (xce->above)); if (above_node && node->prev != above_node) { cache->children = g_list_remove_link (cache->children, node); node->next = above_node->next; if (node->next) node->next->prev = node; node->prev = above_node; above_node->next = node; } Looks like next and prev are the wrong way around... switching them fixes it :-)
Just to see if I understand you right - you are saying, the problem is that the widget is being put underneath (after in the list) the 'above' window, rather than above (before in the list) the 'above' window? (Looks plausible reading the code)
Yes. xce->above is defined in the manpage with: "However, if this member is set to a sibling window, the window whose state was changed is placed on top of this sibling window. Ie 'node' is above 'xce->above'. 'above' is 'the window which node is above' (and should probably be called 'the_lower_window' or something).
Fix now in CVS for stable and HEAD Tue Feb 5 19:13:42 2002 Owen Taylor <otaylor@redhat.com> * gdk/x11/gdkdnd-x11.c (gdk_window_cache_filter): Fix ordering on ConfigureNotify (#56349, Thomas Leonard)
This isn't quite fixed. Now that the new node is (correctly) inserted BEFORE above_node, it can become the first element in the list... this prevents new windows from working with blackbox and fluxbox (sawfish and wmaker are OK). Add the indicated lines to fix... if (above_node && node->prev != above_node) { /* Put the window above (before in the list) above_node */ cache->children = g_list_remove_link (cache->children, node); node->prev = above_node->prev; if (node->prev) node->prev->next = node; else /* ADD THIS!! */ cache->children = node; /* ADD THIS!! */ node->next = above_node; above_node->prev = node; }
Fixed in head, gtk-2-0 and gtk-1-2.