GNOME Bugzilla – Bug 567221
Only show docking bars when needed, not all the time
Last modified: 2009-12-02 19:46:39 UTC
The docking bars in GIMP are currently shown all the time even though they are only useful when one is rearranging the UI. It turns out this is not a trivial problem to solve. This enhancement request hosts an incomplete patch that was produced when this was discussed on gimp-developer [1] so it doesn't get lost. The enhancement request also acts as a reminder to look deeper into this when the time comes. As it makes sense to sort out the details of the docking system when the one-window GIMP option is added I'm setting this on the 2.10 milestone as that is when we IMO should aim for the one-window GIMP option. This bug report can be closed as soon the proper discussion has taken place, the proper specifications has been written and the proper enhancement requests have been filed. [1] https://lists.xcf.berkeley.edu/lists/gimp-developer/2009-January/021379.html
Created attachment 126155 [details] [review] gimp-on-demand-docking-2009-01-10.patch Problems with the patch: * Tends to change the size of the Dock-windows and does not bother to restore them Things that it might make sense to implement: * If changing size of docks add logic that restores them if no change to the UI was made * Only show the docking bars that are close to the cursor when a drag is ongoing.
The resizing problem can easily be fixed by popping up small windows on top and bottom to drop the dockable. I don't think resizing the window is acceptable.
My initial patch used the popup-approach but that became much more complicated with several corner-cases. Using popups also makes the UI 3d (since the user has to cope with stuff-on-stuff). Also I don't see the problem with resizing the window, we already manage the window size. Often adding a new dock results in a bigger window anyway.
If you add a new dockable, resizing the window is completely normal. However if you just start a dnd operation (which you maybe never finish), possibly resizing *all* docks is imo completely unacceptable. And code that resizes them back to whatever size they had before is definitely more ugly than a simple popup window approach (not even thinking about restoring the position of all GtkVPaneds inside the dock).
Using popups is more complicated both for the user and for us to implement so IMO we should definitly look into a solution that continues on the path of the patch. One way to address your concerns is, again: * Only show the docking bars that are close to the cursor when a drag is ongoing. But let's not discuss this to death already :) Let's wait on guiguru to start working on this and put our energy in discussing issues with him rather than with each other.
With Single-window mode in 2.8, this is the time when we shall look into this problem. Setting milestone accordingly.
I couldn't stand how terrible docks in the image window looked so I commited the patch for now: commit 3b721864d714149582f63d08ce6b98701433608c Author: Martin Nordholts <martinn@src.gnome.org> Date: Sun Oct 4 12:58:30 2009 +0200 app: Only show dock separators when rearranging the UI For now, only show dock separators when they are needed, not all the time. We need a better solution eventually, but at least docks in the image window doesn't look terrible any longer. app/widgets/gimpdock.c | 82 +++++++++++++++++++++++++++++++++----------- app/widgets/gimpdock.h | 71 ++++++++++++++++++++------------------ app/widgets/gimpdockbook.c | 10 ++++- 3 files changed, 107 insertions(+), 56 deletions(-)
Even better, they are completely gone now, closing as FIXED (the scope of this bug report is not bigger, it was just hosting a patch): commit 4ccb6504353a8c875080c130d21d71d40fb89c3a Author: Martin Nordholts <martinn@src.gnome.org> Date: Wed Dec 2 20:40:39 2009 +0100 Exterminate GimpDockSeparator Remove all GimpDockSeparator-related code. Seems pointless to keep even the stuff in gtkrc. commit 7b85cf4de8938bfe833de223026bd6e99d585bac Author: Martin Nordholts <martinn@src.gnome.org> Date: Sun Nov 29 18:22:12 2009 +0100 app: Use a GdkWindow instead of GimpDockSeparators for dockable DND 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