-
Martin Nordholts authored
Make drag-and-drop rearrangement of dockables happen directly in the existing widget hierarchy so we don't have to use special, ugly widgets (read GimpDockSeparator:s) for that. More specifically, make edges of dockables and dockbooks have the same semantics as the GimpDockSeparators had. We put a highlight colored GdkWindow on top of the widget in question to highlight these special drop areas. This GdkWindow is not taken into consideration in the GTK+ drag-and-drop code, so it does not interupt the DND interaction. To achive this, there is a problem we must solve: Drag events in GTK+ are propagated inwards and out, but we sometimes want ancenstor widgets to take care of drop events. We solve this by introducing the concept of "drag handlers". A drag handler is asked if it will handle a given drag event, and if it will, a client will let the drag event be propagated upwards in the widget hierarchy. Right now, the GimpPanedBox is the only "drag handler". The code could be generalized more but it doesn't feel worth it at this point. The size of the special drop area is 5px, the same size as the default GtkPaned handles. This is because the plan is to later use these handles as drop areas too. Other changes of interest are: * We need to take care of "drag-motion", "drag-drop" and widget highlightning ourselves. We can not use the GtkDestDefaults conveniences with gtk_drag_dest_set() any longer since we need more control. * Make the drop callback pass the insert index directly instead of a GimpDockSeparator * Add some GIMP_LOG() debug output for DND * Disable the GimpDockSeparator code in GimpToolbox
7b85cf4d