GNOME Bugzilla – Bug 616544
win32 drag and drop (DnD) broken for GTK+ 3
Last modified: 2011-11-21 14:10:36 UTC
Created attachment 159347 [details] Sample code It appears that GtkTreeView reordering does not work anymore in 2.20.0. You'll find the basic sample attached to this report that works fine when executed on GTK+ v2.16.6 for Windows and GTK 2.18.3 on Fedora 12, but does not work when tested with GTK 2.20.0 for Windows. To reproduce the issue try reordering the tree view content with mouse drag and drop.
This appears to be extant in GTK 2.22.1 for windows (using the gtk+-bundle_2.22.1-20101227_win32.zip binary bundle). My application's symptoms are that drags can be initiated but no valid drag targets appear - there's nowhere to drop. I haven't tested this bug's testcase. I'm disappointed to find something like this in a stable release and it has shaken my confidence in the quality of gtk beyond version 2.20.
Me too just ran into this problem. As others stated, drag and drop on Windows worked fine before gtk 2.20. Will there be any fix available soon?
Moving Windows-specific bug to win32 component (I don't have access to a Windows machine so cannot help unfortunately).
Thanks, Kristian. Do you have any thoughts on where the problem might lie? I'm happy to have a poke around but I'm unfamiliar with the code. If it's working on Linux does this suggest that I should be first looking at GDK rather than gtktreeview.c? PS. FYI I notice that something similar is happening on OS X. While drag and drop is functional, the UI feedback indicating drop targets for the user is missing. I will try to ensure a bug is raised about this. PPS. Who is the maintainer for GTK on win32?
Created attachment 192989 [details] [review] Revert drag-and-drop for Windows from 2.20.0 to 2.18.9 I tried moving different files around, until I found out where the problem resides. It seems that the changes in GDK for drag-and-drop in Windows between versions 2.20.0 and 2.18.9, in "gdk/win32/gdkdnd-win32.c", caused the problem. You may try reverting it to the older one using the patch in this comment, which will revert "gdk/win32/gdkdnd-win32.c" and remove some calls to new functions in "gdk/win32/gdkevents-win32.c" and "gdk/win32/gdkproperty-win32.c". I tested it using Wine in Ubuntu Linux. I hope that a fix will be available soon, because I need it in my current project (which will be used in Windows). Note: If you're using the 2.20.0 sources, make sure to edit "configure.in" replacing "gio-unix-2.0" with "gio-2.0" in GDK_PACKAGES variable, then run "autoreconf". It is a bug in 2.20.0.
It seems that in this commit the problem started: eb21a7df290936223f6a80cef36b52a8c68a1d22 (in branch gtk-2-20). http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-20&id=eb21a7df290936223f6a80cef36b52a8c68a1d22
Added the author of the commit in question (Tor Lillqvist <tml@iki.fi>) Hopefully he can shed some light of what happened? I am not a member of the GTK dev team but I think that this bug should be treated with a higher prio. For some apps it can be a shop stopper.
Created attachment 196922 [details] [review] win32: Fix DnD when drag icon is below the pointer Independently rediscovered in this thread on gtk-list: https://mail.gnome.org/archives/gtk-list/2011-September/msg00020.html This patch is less crude than attachment #192989 [details] in that it only reverts the gdk_drag_find_window_for_screen logic to what it was before commit eb21a7df290936223f6a80cef36b52a8c68a1d22 without breaking the wip OLE2 DnD code.
*** Bug 641056 has been marked as a duplicate of this bug. ***
*** Bug 641924 has been marked as a duplicate of this bug. ***
*** Bug 652235 has been marked as a duplicate of this bug. ***
*** Bug 657724 has been marked as a duplicate of this bug. ***
Created attachment 196936 [details] [review] win32: Fix DnD when drag icon is below the pointer First patch replaced gdk_window_foreign_new_for_display with gdk_win32_window_foreign_new_for_display. No need to do that, so updated patch. Thanks to pbor for pointing this out!
Created attachment 196941 [details] [review] win32: Fix DnD when drag icon is below the pointer [14:50] <pbor> dieterv: btw, not really a bug or anything, but I find the line *dest_window = gdk_win32_handle_table_lookup a bit inelegant [14:51] <pbor> dieterv: since it assigns *dest_window which is then overwritten in both cases [14:51] <pbor> I'd use a local var [14:57] <dieterv> pbor: ok [15:06] <dieterv> pbor: out of curiosity, what would you name that local var? [15:07] <dieterv> I went with simply dw because I'm used to such names, but I'm not sure if that fits GTK+ code [15:07] <pbor> dieterv: yeah, I guess I'd just have use w [15:07] <pbor> :) [15:08] <dieterv> heh, looks like dw will fit in just fine then :)
Created attachment 196999 [details] [review] [gtk-2-24] win32: Fix DnD when drag icon is below the pointer Added bug link to commit message
Patch doesn't apply cleanly to master - can you update it ?
(In reply to comment #16) > Patch doesn't apply cleanly to master - can you update it ? attachment #196999 [details] is intended for the gtk-2-24 branch. I've looked at forward porting this to master a couple of hours ago, but there seem to be other -more general- DnD related problems there. No single drag operation could be started without crashing. gdb's backtrace didn't make much sense, will have a fresh look tomorrow for gtk3...
Hi Dieter, Thanks for following this up-tested on the MSVC build with the supplied test program. It worked, at least for the test program here. :) (In reply to comment #17) > > attachment #196999 [details] is intended for the gtk-2-24 branch. I am changing the affected version of this to 2.24.x as this is intended for that too. > No single drag operation could be started without crashing. > gdb's backtrace didn't make much sense, will have a fresh look > tomorrow for gtk3... Is there anything that I can help to do, such as running some specific item through the VS debugger and provide a call stack from it? Thank you, and God Bless!
Hi Fan, (In reply to comment #18) > Thanks for following this up-tested on the MSVC build with the supplied test > program. It worked, at least for the test program here. :) There's also the testtreeview and testdnd programs in the source tree tests directory. Those have been really helpful :) > I am changing the affected version of this to 2.24.x as this is intended for > that > too. Thanks! I've also marked the patch description with [gtk-2-24] to make it extra clear what branch it's supposed to go into. Just in case we find a fix for [master] sometime soon ;) > > No single drag operation could be started without crashing. > > gdb's backtrace didn't make much sense, will have a fresh look > > tomorrow for gtk3... Have been digging around in the commit logs: c53ec081ceeb84ee2b3088e1c3ec986c89e954af and 1d838f586c574af7f05c618a337f8d34a58d9125 look related. I guess Hans is correct in his commit message with the remark "There are sure regressions..." ;) > Is there anything that I can help to do, such as running some specific item > through the VS debugger and provide a call stack from it? Could you run the testdnd program (it's still there in master), initiate a DnD operation from the "Drag Here" GtkButton towards the "Drop Here" GtkLabel and see what happens? Backtrace from gdb looks like this: $ gdb /d/dev/gnome.org/gnome-windows/checkout/gtk+/git/build/tests/testdnd.exe GNU gdb (GDB) 7.3 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "mingw32". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from d:\dev\gnome.org\gnome-windows\checkout\gtk+\git\build\tests\testdnd.exe...done. (gdb) run Starting program: d:\dev\gnome.org\gnome-windows\checkout\gtk+\git\build\tests\testdnd.exe [New Thread 91104.0x15df4] [New Thread 91104.0x14ff8] warning: BTMMHOOK 20.09.2011 09:44:59 Thread<15DF4> Hook DLL loaded Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) thread apply all bt full
+ Trace 228498
Thread 2 (Thread 91104.0x14ff8)
Created attachment 197020 [details] [master] DnD backtrace (In reply to comment #19) > Backtrace from gdb looks like this: Ugh, formatting ate the bt. Attached instead.
Created attachment 197214 [details] VS Debugger monitor screenshots .zip Hi Dieter, Sorry for the delay, as I was away on a family trip during the past 2 days... (We might want to open another bug for any further patches against master here though) I built GTK+ 3.1.92 on VS2008 debug mode and ran the program you asked me to-the program crashed in "void gdk_drag_status" gdkdnd.c at line 279 with an access violation (aka segfault). The attached .zip is the VS debugger monitor screenshots at the time of the crash. Please let me know if further info is required. God bless.
Finally figured out the GTK3 DnD problem too. Turns out if your compare the win32 and X11 backends and stare at them long enough, patterns start to emerge. Conclusion: it is simply win32's gdk_drag_context_new that is wrongly returning a GdkDragContext instead of a GdkWin32DragContext cast to GdkDragContext on the master branch. Thank you motif_drag_context_new :) Will need to clean up these patches for master (did some cleanup and refactoring while at it). If all goes well they should land here on bgo sometime soon. (In reply to comment #20) > Ugh, formatting ate the bt. Attached instead. Turns out that's not true, the "Trace 228498" link next to the expander button takes you to the full bt. It's the expander thing that only shows the first (and uninteresting) part. Lesson learned I guess. (In reply to comment #21) > Sorry for the delay, as I was away on a family trip during the past 2 days... No problem. Hope you had a good time! > (We might want to open another bug for any further patches against master here > though) I'll see how big the patch-set becomes after cleaning them up. If there's not that many, maybe it's best to keep them together with the 2.24 fix for easier maintainer review? I wonder if git-bz works with msysgit... > I built GTK+ 3.1.92 on VS2008 debug mode and ran the program you asked me > to-the > program crashed in "void gdk_drag_status" gdkdnd.c at line 279 with an access > violation (aka segfault). > > The attached .zip is the VS debugger monitor screenshots at the time of the > crash. Please let me know if further info is required. Thank you! I've looked over them but sadly it doesn't show the GdkDragContextClass vfuncs in there. It's there that, just before the crash, things are wrong with find_window, drag_status, drag_motion, etc all pointing to 0x0 instead of their respective win32 implementations. When the patches land, do you think we could we coordinate testing (with mingw, mingw-w64 and msvc) on windows-devel-list and report back here? That may give some extra weight to the validity of these fixes. Just a thought :)
(In reply to comment #22) > I'll see how big the patch-set becomes after cleaning them up. If there's > not that many, maybe it's best to keep them together with the 2.24 fix > for easier maintainer review? I wonder if git-bz works with msysgit... That's fine with me though-just mentioned in case maintainer(s) might feel that is better. > Thank you! I've looked over them but sadly it doesn't show the > GdkDragContextClass vfuncs in there. It's there that, just before > the crash, things are wrong with find_window, drag_status, drag_motion, > etc all pointing to 0x0 instead of their respective win32 implementations. > > When the patches land, do you think we could we coordinate testing > (with mingw, mingw-w64 and msvc) on windows-devel-list and report back > here? That may give some extra weight to the validity of these fixes. > > Just a thought :) I will try to see whether the expandable nodes in the debugger monitor window contains anything regarding the GdkDragContextClass vfuncs in the next day or two. No probs about coordinating testing on the MSVC part (the projects will take care of 32-bit and x86-64 builds, BTW) on my side. :) Thanks, and God bless!
Created attachment 197370 [details] [review] [gtk-2-24] win32: dnd should not be registerd for offscreen windows
Created attachment 197372 [details] [review] [master] win32: dnd should not be registerd for offscreen windows
Created attachment 197373 [details] [review] [master] win32: get rid of GdkDragContextPrivateWin32 and related machinery.
Created attachment 197374 [details] [review] [master] win32: Fix DnD when drag icon is below the pointer
Attached patches bring DnD up to speed for both GTK 2.24 and GTK 3. I do seem to have either introduced or exposed some fresh new bug in GDK 3. I'm hoping exposed though. Here's why I think what I'm seeing is not directly related to these DnD fixes: What happens is that with the patches for master applied, GTK 3's testdnd.exe DnD works fine as long as you do not move the pointer after the drop. Once you do, it's boom! Bt (with current tips of GLib 2.30 branch and GTK+ master) looks like the following. Note that I left 30 seconds between gdk_drag_context_finalize and moving the pointer which only then caused SIGSEGV, Segmentation fault. If we agree this is not related to DnD, it's probably best to file a separate bug report on this and start asking people to build GTK3 with these patches with various compilers - hi Fan :) - and test various Windows version. Sounds good? Thanks! $ GDK_DEBUG=dnd gdb /d/dev/gnome.org/gnome-windows/checkout/gtk+/git/build/tests/testdnd.exe GNU gdb (GDB) 7.3 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "mingw32". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from d:\dev\gnome.org\gnome-windows\checkout\gtk+\git\build\tests\testdnd.exe...done. (gdb) r Starting program: d:\dev\gnome.org\gnome-windows\checkout\gtk+\git\build\tests\testdnd.exe [New Thread 55900.0xd8bc] [New Thread 55900.0xd900] gdk_window_register_dnd: 000F0742 warning: BTMMHOOK 23.09.2011 22:52:52 Thread<D8BC> Hook DLL loaded gdk_drag_context_init 012F5010 gdk_drag_find_window: 007A079E +69+98: 000F0742: 000F0742 LOCAL gdk_drag_motion: LOCAL suggested=COPY, possible=COPY|MOVE context=012F5010:{actions=COPY|MOVE,suggested=,action=} local_send_enter: context=012F5010 current_dest_drag=00000000 gdk_drag_context_init 012F5060 local_send_motion: context=012F5010 (69,98) current_dest_drag=012F5060 returning FALSE context=012F5010:{actions=COPY|MOVE,suggested=COPY,action=} gdk_selection_owner_set_for_display: 004B06C6 LocalDndSelection gdk_win32_selection_add_targets: 004B06C6: LocalDndSelection: STRING gdk_win32_selection_add_targets: 004B06C6: LocalDndSelection: text/plain gdk_win32_selection_add_targets: 004B06C6: LocalDndSelection: application/x-rootwindow-drop gdk_win32_selection_add_targets: 004B06C6: LocalDndSelection: DELETE gdk_drag_status: COPY context=012F5060:{actions=COPY|MOVE,suggested=COPY,action=} gdk_drag_find_window: 007A079E +68+94: 000F0742: 000F0742 LOCAL gdk_drag_motion: LOCAL suggested=COPY, possible=COPY|MOVE context=012F5010:{actions=COPY|MOVE,suggested=COPY,action=COPY} local_send_motion: context=012F5010 (68,94) current_dest_drag=012F5060 returning FALSE context=012F5010:{actions=COPY|MOVE,suggested=COPY,action=COPY} gdk_drag_status: COPY context=012F5060:{actions=COPY|MOVE,suggested=COPY,action=COPY} gdk_drag_find_window: 007A079E +67+94: 000F0742: 000F0742 LOCAL gdk_drag_motion: LOCAL suggested=COPY, possible=COPY|MOVE context=012F5010:{actions=COPY|MOVE,suggested=COPY,action=COPY} local_send_motion: context=012F5010 (67,94) current_dest_drag=012F5060 returning FALSE context=012F5010:{actions=COPY|MOVE,suggested=COPY,action=COPY} gdk_drag_status: COPY context=012F5060:{actions=COPY|MOVE,suggested=COPY,action=COPY} gdk_drag_find_window: 007A079E +67+93: 000F0742: 000F0742 LOCAL gdk_drag_motion: LOCAL suggested=COPY, possible=COPY|MOVE context=012F5010:{actions=COPY|MOVE,suggested=COPY,action=COPY} local_send_motion: context=012F5010 (67,93) current_dest_drag=012F5060 returning FALSE context=012F5010:{actions=COPY|MOVE,suggested=COPY,action=COPY} gdk_drag_status: COPY context=012F5060:{actions=COPY|MOVE,suggested=COPY,action=COPY} gdk_drag_drop local_send_drop: context=012F5010 current_dest_drag=012F5060 gdk_selection_owner_get: LocalDndSelection = 004B06C6 Received "I'm Data!" in label gdk_drop_finish gdk_drop_finish gdk_drop_reply gdk_selection_owner_get: LocalDndSelection = 004B06C6 gdk_selection_owner_set_for_display: 00000000 LocalDndSelection gdk_drag_context_finalize 012F5010 Program received signal SIGSEGV, Segmentation fault. 0x68610d76 in magazine_chain_pop_head (magazine_chunks=0xa96db0) at d:/dev/gnome.org/gnome-windows/checkout/glib/git/src/glib/gslice.c:492 492 (*magazine_chunks)->data = chunk->next; (gdb) thread apply all bt full
+ Trace 228558
Thread 2 (Thread 55900.0xd900)
Thread 1 (Thread 55900.0xd8bc)
(In reply to comment #28) > Attached patches bring DnD up to speed for both GTK 2.24 and GTK 3. > I do seem to have either introduced or exposed some fresh new bug > in GDK 3. I'm hoping exposed though. Here's why I think what I'm > seeing is not directly related to these DnD fixes: >.... (snip) > If we agree this is not related to DnD, it's probably best to file a > separate bug report on this and start asking people to build GTK3 with > these patches with various compilers - hi Fan :) - and test various > Windows version. Sounds good? > > Thanks! Hi Dieter, I got your message, sounds good to me on the MSVC part, hopefully the VS debugger will show something better here and there. p.s. Time didn't go in my favor on this part, as some things got in the way. Will try to get the Debugger output for GdkDragContextClass vfuncs ASAP. Sorry. Thank you, and God bless!
Created attachment 197441 [details] [review] gdkdnd-win32.c: Fix compilation on C89 compilers Hi Dieter, I have to come up with this patch against your fixes as your fixes declared variables in the middle of the block, which C89 compilers like MSVC do not like. Thanks, and God Bless.
Created attachment 197442 [details] VS Debugger output Hi Dieter, The MSVC-built version of master also crashed at that same spot--the drag succeeded but program will crash once the "Drag Here" is highlighted, as it seems. The debugger window display is shown on the attached .png file. Thank you, and God bless!
Created attachment 197443 [details] The actual VS debugger window Sorry, I attached the wrong image...
Created attachment 197444 [details] The actual debugger image (again) Ugh... keep hitting the wrong options in BZ. Sorry :|
Hi Dieter, The 2.24.x tests seemed to run fine on VS2008/x86 and VS2010/x86 and VS2010/x64 on Windows7/x64 and WindowsXP/x86 (32-bit configs only) Thank you, and God bless!
(In reply to comment #30) > I have to come up with this patch against your fixes as your fixes > declared variables in the middle of the block, which C89 compilers > like MSVC do not like. I've squashed your C89 fixes and will be attaching a new set of patches shortly. Apologies for not noticing this, especially since I've already been bitten by it myself a couple of years ago... (In reply to comment #31) > Created an attachment (id=197442) [details] > VS Debugger output > > Hi Dieter, > > The MSVC-built version of master also crashed at that same spot--the drag > succeeded but program will crash once the "Drag Here" is highlighted, as it > seems. > > The debugger window display is shown on the attached .png file. Thanks you. I'm slowly getting convinced something's off in what looks like gdkevents-win32.c, but haven't been able to pinpoint it yet. So unless I'm wrong (and please correct me if I am), this will definitely be material for another bug report... (In reply to comment #34) > Hi Dieter, > > The 2.24.x tests seemed to run fine on VS2008/x86 and VS2010/x86 and VS2010/x64 > on Windows7/x64 and WindowsXP/x86 (32-bit configs only) > > Thank you, and God bless! That's great, thank you for doing these tests! Looks like it's good to ask approval to push the 2.24 patches then, no? Thanks, Dieter
Created attachment 197517 [details] [review] [master] win32: dnd should not be registerd for offscreen windows
Created attachment 197518 [details] [review] [master] win32: get rid of GdkDragContextPrivateWin32 and related machinery.
Created attachment 197519 [details] [review] [master] win32: Fix DnD when drag icon is below the pointer
Hi Dieter, (In reply to comment #28) > Bt (with current tips of GLib 2.30 branch and GTK+ master) looks like > the following. Note that I left 30 seconds between gdk_drag_context_finalize > and moving the pointer which only then caused SIGSEGV, Segmentation fault. > My gut guess is that if the same thing happens on GLib-2.28/GTK+-3.0, then it's likely that it's not a GLib problem (it seems to me that GTK+-3.0.x and the current GTK+-3.2.x use the -same- gdkdnd-win32.c, as Hans was the last person to commit to that) (In reply to comment #35) > Thanks you. I'm slowly getting convinced something's off in what > looks like gdkevents-win32.c, but haven't been able to pinpoint > it yet. So unless I'm wrong (and please correct me if I am), this > will definitely be material for another bug report... > Agreed. > > That's great, thank you for doing these tests! Looks like it's good > to ask approval to push the 2.24 patches then, no? No probs, I'm also one who likes to see GTK+ in a better state on Windows, hence I worked on the VS support. Agreed with you about proposal to ask to push into gtk-2-24--anyone else looking here? :) Thank you, and God bless!
(In reply to comment #39) > My gut guess is that if the same thing happens on GLib-2.28/GTK+-3.0, then it's > likely that it's not a GLib problem (it seems to me that GTK+-3.0.x and the > current GTK+-3.2.x use the -same- gdkdnd-win32.c, as Hans was the last person > to commit to that) Yeah, tried testing against GLib 2.28 last week and failed due to this: Requested 'glib-2.0 >= 2.29.14' but version of GLib is 2.28.8 Did some more digging this morning and looks like the patches for master need more work: WM_DROPFILES doesn't function yet. Ugh :( > Agreed with you about proposal to ask to push into gtk-2-24--anyone else > looking here? :) Good. I'll ask again for gtk-2-24 in #gtk+ tonight (am behind restrictive proxy atm). Thanks!
(In reply to comment #40) > > Yeah, tried testing against GLib 2.28 last week and failed due to this: > Requested 'glib-2.0 >= 2.29.14' but version of GLib is 2.28.8 Hi Dieter, It seems to me that the same thing goes for GTK+-3.0.12 with GLib-2.28.8. I didn't collect VS debugger output, but it does seem to be the same problem as the triggering conditions are the same (with master). p.s. We might want to separate locations of where stable and unstable binaries are installed on Windows God bless!
(In reply to comment #41) > It seems to me that the same thing goes for GTK+-3.0.12 with GLib-2.28.8. I > didn't collect VS debugger output, but it does seem to be the same problem > as the triggering conditions are the same (with master). Good to know. Limits at least GLib as the cause and further confirms my suspicion about gdkevents-win32.c :) Thanks! > p.s. We might want to separate locations of where stable and unstable binaries > are installed on Windows Don't really understand what you mean by installing here, sorry :/ My dev environment (MinGW/MSYS) already has separate locations for just about everything. Note I'm using out of tree builds, i $(src_dir)!=$(dst_dir) where possible: d:\dev\gnome.org\gnome-windows\checkout\glib\2.28\dist d:\dev\gnome.org\gnome-windows\checkout\glib\2.28\build d:\dev\gnome.org\gnome-windows\checkout\glib\2.28\src d:\dev\gnome.org\gnome-windows\checkout\glib\2.28\glib-2.28.sh d:\dev\gnome.org\gnome-windows\checkout\glib\git\dist d:\dev\gnome.org\gnome-windows\checkout\glib\git\build d:\dev\gnome.org\gnome-windows\checkout\glib\git\src d:\dev\gnome.org\gnome-windows\checkout\glib\git\glib-git.sh d:\dev\gnome.org\gnome-windows\checkout\gtk+\2.24\dist d:\dev\gnome.org\gnome-windows\checkout\gtk+\2.24\build d:\dev\gnome.org\gnome-windows\checkout\gtk+\2.24\src d:\dev\gnome.org\gnome-windows\checkout\gtk+\2.24\gtk+-2.24.sh d:\dev\gnome.org\gnome-windows\checkout\gtk+\git\dist d:\dev\gnome.org\gnome-windows\checkout\gtk+\git\build d:\dev\gnome.org\gnome-windows\checkout\gtk+\git\src d:\dev\gnome.org\gnome-windows\checkout\gtk+\git\gtk+-git.sh and the list goes on and on for each module... Each module has a shell script that lists the dependencies needed to get that specific module built, sets up envvars like LINGUAS, PATH, PKG_CONFIG_PATH, XDG_DATA_DIR, etc and takes an optional parameter which can be: all (do a complete clean & build) clean (rm -rf build && rm -rf dist) autogen (NO_CONFIGURE=1 ./autogen) configure (./configure --prefix=../dist) make (make -j3 install) shell (set up environment and drop me in a bash shell by calling "sh --login -i") ... Running without the optional parameter simply prints a list of dependencies and their location on disk to stdout and exits. Running with the "shell" argument allows testing a particular module against it's required dependencies. gdb, dependency walker and ollydbg all work fine in this setup. Pretty comfortable and flexible way of working, heavily inspired by Tor's original build scripts (except my scripts don't do packaging).
gtk-2-24 patches pushed but leaving this bug open to track progress on the patches for master, changed summary and version to reflect this.
I pushed all the patches to master, and fixed an issue that caused the crash: http://git.gnome.org/browse/gtk+/commit/?id=9275b87b6a3a0616b782b10c77ef12458185a869 Testdnd.exe works in master now
The original sample also works for me. I'm closing this bug. If there are any outstanding dnd issues someone is seeing we should handle that in a new bug.