Could you give a couple of examples of tools exhibiting this
behaviour? (with a language code, if this is a translations issue,
please).

I think this could be addressed for 2.0, but since this is in the
realm of GUI creation from properties, perhaps Sven has other ideas...

Dave.

Last CVS>Toolbox && docked Tool Options in tolbox
standard Debian/unstable gtk theme

eg:

select any regions> Feather Regions>Radius 
||
Paint > Opacity
||
Smudge||Blur > Rate
||
Airbrush>Rate && Pressure
and more

to full display I must Use 8x4 (tool icon) or undock tool Options
but I like 5x6 and docked ;-) 

LC_ALL=C

I don't think we will change this for 2.0. The suggested toolbox size
with docked tool options is indeed 8x4. If you want a narrower
toolbox, you will have to place the tool options someplace else.

Of course in general it is desirable to keep the tool-options as
narrow as possible.

1. hmm 8x4 mayby 1xX 
this is imho to big 
most toolbox in other programs have 2xX or 3xX  and this is IMHO optimaly 


ok undock is the option 
but ... I like this new idea 

2. 8x4 in some cases is to small too
ie "fill gradient"
in traslation may be worst

3. maybe change icon size to biger ;-P

Putting on 2.2. This shouldn't be considered a blocker for that
release, though.

Dave.

*** Bug 142052 has been marked as a duplicate of this bug. ***

*** Bug 153516 has been marked as a duplicate of this bug. ***

Not only the positions of the controls, but their widths are excessive (e.g. 335
pixels for simple number editing control). See screenshot of the bug
http://bugzilla.gnome.org/show_bug.cgi?id=153516

The text tool options are a special problem but known.

2004-10-08  Michael Natterer  <mitch@gimp.org>

	Made the text options about two toolbox grid columns smaller.
	Addresses bug #122862.

	* app/widgets/gimppropwidgets.c (gimp_prop_size_entry_new): use
	the number of digits of the property's max_val plus two as number
	of chars for the sizeentry'y spinbutton (instead of always 10 as
	before).

	* app/tools/gimptextoptions.c (gimp_text_options_gui): GtkEntry
	has a minimal width of 150 pixels (eek). Set a silly small minimal
	width instead (the entry expands to the available width anyway).

Further changes will have to be postponed for the next development cycle.
Bumping from the 2.2 milestone.

*** Bug 312596 has been marked as a duplicate of this bug. ***

I think this is a very efficient way to use the space - for the sliders at least: http://thorwil.wordpress.com/category/widgets/page/5/

Combined with the fan-slider lower on the page, the mouse would give enough precision to skip the spinbutton.

It looks like this one can be closed now thanks to new sliders that combine label, spinbox and slider.

There is still the issue of labels in front of combo boxes, which can
be horribly long when translated. Setting 2.10 milestone so it attracts
some attention.

*** Bug 676145 has been marked as a duplicate of this bug. ***

This addresses the combo boxes with labels in front. Still need to
set the "ellipsize" property of the combos to make them really not
grow insanely for translated strings.

commit a5d2123adf316da0f6528bfc7be526df34775620
Author: Michael Natterer <mitch@gimp.org>
Date:   Mon Jun 3 16:40:24 2013 +0200

    app: use the new combo box label in many tool options
    
    and generally clean up a bit. Reuse the clone options code in the
    perspective clone options. Addresses bug #122862.

 app/tools/Makefile.am                |    2 +
 app/tools/gimpalignoptions.c         |   11 +---
 app/tools/gimpblendoptions.c         |   19 ++----
 app/tools/gimpbucketfilloptions.c    |   12 +---
 app/tools/gimpcloneoptions-gui.c     |  107 ++++++++++++++++++++++++++++++++++
 app/tools/gimpcloneoptions-gui.h     |   25 ++++++++
 app/tools/gimpclonetool.c            |   52 +----------------
 app/tools/gimpgegltool.c             |    2 +-
 app/tools/gimphealtool.c             |   13 +----
 app/tools/gimppaintoptions-gui.c     |   26 ++-------
 app/tools/gimpperspectiveclonetool.c |   45 +-------------
 app/tools/gimprectangleoptions.c     |    4 +-
 app/tools/gimpregionselectoptions.c  |   13 +----
 app/tools/gimptransformoptions.c     |   26 +++------
 14 files changed, 168 insertions(+), 189 deletions(-)

commit 418a310f360344cf8390ea21104837c7e2fd862d
Author: Michael Natterer <mitch@gimp.org>
Date:   Mon Jun 3 16:36:25 2013 +0200

    libgimpwidgets: add a "label" property and API to GimpIntComboBox
    
    If set, the label is displayed left-aligned inside the combo box, and
    the normal content moves to the right. Reconfigure the combo's
    contents when the popup is shown/hidden, so the popup widget is not
    affected by the label. This requires an evil hack because of a bug in
    GtkCellView. The hack automatically disables itself once GTK+ 2.24.19
    (which has a fix) is used.

 libgimpwidgets/gimpintcombobox.c |  244 ++++++++++++++++++++++++++++++++++----
 libgimpwidgets/gimpintcombobox.h |   66 ++++++-----
 libgimpwidgets/gimpwidgets.def   |    2 +
 3 files changed, 257 insertions(+), 55 deletions(-)

Mitch > what were you expecting to do on this one? Is this the only remaining task:

> Still need to set the "ellipsize" property of the combos to make them really not grow insanely for translated strings.

What did you mean exactly? Because I already see there is a "ellipsize" property on GimpIntComboBox, which operates on the contents items (not the label). Did you want to have it work also on the label?

I feel this bug report should be either quickly dealt with or pushed to 3.0 milestone.

That's a long time ago :) Maybe we should just look carefully at all
tool options again, and if none of them is unreasonably wide, just
close this bug as FIXED...

Well ok. I think I did them all. I don't see anything which strikes me as "unreasonably wide". So let's just close as FIXED.

If anyone disagrees, feel free to reopen. Or even better, if you have an issue with a specific widget, open a new bug report for the specific issue. Much easier to deal with a lot of accurate yet small reports, than huge reports mixing various issues.