After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 150593 - Be able to dock dialogs in blank area under toolbox
Be able to dock dialogs in blank area under toolbox
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: User Interface
2.0.x
Other All
: Normal enhancement
: 2.4
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2004-08-19 22:38 UTC by Brion Vibber
Modified: 2005-09-12 17:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Brion Vibber 2004-08-19 22:38:35 UTC
This is related to the problem that causes people to report things like bug 132207; the current behavior 
is I think bad from a usability standpoint:

1) Drag the tool options dialog away from the toolbox: it pops up to a separate dialog, leaving a big 
blank area under the main toolbox.
2) Drag the tool options dialog back to the big inviting blank area where it used to be.
3) Oops! The dialog changes position maybe, but remains separate.

While some of us will then go on to aim for the tiny unmarked strip as a drop target, this is 
pretty confusing behavior. Dropping on the blank area ought to dock the dialog there.
Comment 1 Sven Neumann 2004-08-19 23:08:28 UTC
If it was that easy, we'd have implemented that a long time ago already.
Lowering priority since it's simply not doable with the current docks
implementation.
Comment 2 weskaggs 2004-08-20 14:54:39 UTC
Might as well confirm it, anyway, since it is a reasonable thing to want.
Comment 3 weskaggs 2004-08-20 14:55:21 UTC
Might as well confirm it, anyway, since it is a reasonable thing to want.
Comment 4 Alan Horkan 2005-07-03 16:56:27 UTC
it might help disabuse people of trying to use this space as a target if the
toolbox resized itself to clean up the dead space.  

In the standard dock the whole thing is a drop target.  What if the standard
tools were treated as just another docked Palette? (or would that make no
different to the techincal difficulties?)
Comment 5 Sven Neumann 2005-07-03 18:35:48 UTC
The right thing to do here is to change the separator that serves as dock target
to expand so that it takes up the space which is now empty.
Comment 6 Michael Natterer 2005-09-11 21:08:45 UTC
Fixed in CVS:

2005-09-11  Michael Natterer  <mitch@gimp.org>

	* app/widgets/gimptoolbox.c (gimp_toolbox_book_added)
	(gimp_toolbox_book_removed): if there is no dockbook added, expand
	the separator and add a label telling the user that she can drop
	dockables there. Fixes bug #150593.
Comment 7 Sven Neumann 2005-09-11 23:01:54 UTC
That doesn't work too well yet. There are two problems remaining:

(1) The label is not line-wrapped properly. We probably need to make the
separator a real widget and have it set the label width for this to work nicely.

(2) The label is only added if the last dockable is removed. It won't appear and
the separator won't expand if no dockable is ever added to a newly created dock.
Comment 8 Michael Natterer 2005-09-12 17:53:17 UTC
Fixed again:

2005-09-12  Michael Natterer  <mitch@gimp.org>

	Really fix bug #150593:

	* app/widgets/Makefile.am
	* app/widgets/widgets-types.h
	* app/widgets/gimpdockseparator.[ch]: new widget implementing the
	droppable separator bar in docks.

	* app/widgets/gimpdock.c: use it and removed local separator
	utility functions.

	* app/widgets/gimptoolbox.c: use GimpDockSeparator API to show/hide
	the label. Expand the separator initially.

	* themes/Default/gtkrc
	* themes/Small/gtkrc: the separator height style property moved
	from GimpDock to GimpDockSeparator.