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 122862 - Some settings in Tool Options are too long
Some settings in Tool Options are too long
Product: GIMP
Classification: Other
Component: User Interface
git master
Other All
: Normal enhancement
: 2.10
Assigned To: GIMP Bugs
: 142052 153516 312596 676145 (view as bug list)
Depends on:
Reported: 2003-09-21 08:45 UTC by Ar't
Modified: 2017-03-25 00:21 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Ar't 2003-09-21 08:45:10 UTC
window Tool Option is overloaded
some option use

text: [============++====] [80%=]

maybe beter use:

text:         [80%=]

btw Don't forget about translators ("text" sometimes is long)
Comment 1 Dave Neary 2003-09-21 10:05:35 UTC
Could you give a couple of examples of tools exhibiting this
behaviour? (with a language code, if this is a translations issue,

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...

Comment 2 Ar't 2003-09-22 08:31:06 UTC
Last CVS>Toolbox && docked Tool Options in tolbox
standard Debian/unstable gtk theme


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 ;-) 

Comment 3 Sven Neumann 2003-09-22 11:08:08 UTC
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.
Comment 4 Ar't 2003-09-22 13:53:11 UTC
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
Comment 5 Dave Neary 2004-02-06 14:58:01 UTC
Putting on 2.2. This shouldn't be considered a blocker for that
release, though.

Comment 6 Sven Neumann 2004-05-07 09:21:08 UTC
*** Bug 142052 has been marked as a duplicate of this bug. ***
Comment 7 Sven Neumann 2004-09-23 11:45:17 UTC
*** Bug 153516 has been marked as a duplicate of this bug. ***
Comment 8 Alexander Rabtchevich 2004-09-23 11:55:23 UTC
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
Comment 9 Sven Neumann 2004-09-23 12:12:45 UTC
The text tool options are a special problem but known.
Comment 10 Michael Natterer 2004-10-08 14:15:54 UTC
2004-10-08  Michael Natterer  <>

	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

	* 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).
Comment 11 Sven Neumann 2004-10-22 15:35:13 UTC
Further changes will have to be postponed for the next development cycle.
Bumping from the 2.2 milestone.
Comment 12 Michael Schumacher 2005-08-04 17:27:19 UTC
*** Bug 312596 has been marked as a duplicate of this bug. ***
Comment 13 Thomas D Ahle 2008-04-28 20:30:00 UTC
I think this is a very efficient way to use the space - for the sliders at least:

Combined with the fan-slider lower on the page, the mouse would give enough precision to skip the spinbutton.
Comment 14 Alexandre Prokoudine 2011-08-11 16:53:49 UTC
It looks like this one can be closed now thanks to new sliders that combine label, spinbox and slider.
Comment 15 Michael Natterer 2012-05-16 22:37:52 UTC
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.
Comment 16 Michael Natterer 2012-05-16 22:38:47 UTC
*** Bug 676145 has been marked as a duplicate of this bug. ***
Comment 17 Michael Natterer 2013-06-03 14:43:57 UTC
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 <>
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/                |    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 <>
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(-)
Comment 18 Jehan 2017-03-24 03:11:57 UTC
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.
Comment 19 Michael Natterer 2017-03-24 10:20:48 UTC
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...
Comment 20 Jehan 2017-03-25 00:21:04 UTC
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.