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 104549 - GtkToolbar has major drawing issues
GtkToolbar has major drawing issues
Product: libgnomeui
Classification: Deprecated
Component: general
Other Linux
: High normal
: future
Assigned To: libgnomeui maintainers
Usability Team
Depends on: 106335 106336 106337 106342 106361
Reported: 2003-01-27 19:39 UTC by Alex Duggan
Modified: 2005-03-04 05:56 UTC
See Also:
GNOME target: ---
GNOME version: ---

download this screenshot and zoom in to 400% and look at the circled areas. (18.59 KB, image/png)
2003-01-27 19:39 UTC, Alex Duggan
yelp's toolbar magnified with xmag (5.77 KB, image/png)
2003-01-27 19:41 UTC, Alex Duggan
bonobo (MrProject), glade (Glade), plain GTK+ (gtk-demo) [from left to right] (2.47 KB, image/png)
2003-01-29 20:16 UTC, Christian Neumair
Patch to remove the 1 extra pixel Glade toolbar space. I haven't figured out how to make the toolbar bigger though. (455 bytes, patch)
2003-02-02 10:42 UTC, Hongli Lai
none Details | Review
Patch to fix Glade's own toolbar. (437 bytes, patch)
2003-02-02 11:45 UTC, Hongli Lai
none Details | Review
Fix to make gnome the best desktop on the planet (785 bytes, patch)
2003-07-03 11:09 UTC, Soren Sandmann Pedersen
none Details | Review

Description Alex Duggan 2003-01-27 19:39:02 UTC
A lot of GNOME 2.x apps that have toolbars that use glade-2 to generate the
source code or to generate a .glade file which is later parsed with
libglade have a 1 pixel row of white space that should not be there. 
Applications that have a bonobo window do not have this problem.  See
attached screenshots for more info.

GNOME 2.x apps that have this problem:

 * fileroller
 * yelp
 * glade
 * memprof
 * mergeant
 * gnumeric
 * mahjongg

I'm not sure if this is a glade or a libglade bug, but it seems that
glade-2 is generating bad xml.
Comment 1 Alex Duggan 2003-01-27 19:39:53 UTC
Created attachment 13855 [details]
download this screenshot and zoom in to 400% and look at the circled areas.
Comment 2 Alex Duggan 2003-01-27 19:41:09 UTC
Created attachment 13856 [details]
yelp's toolbar magnified with xmag
Comment 3 Alex Duggan 2003-01-27 19:54:04 UTC
Upon further examination, it appears that the toolbars in these glade
generated apps are a few pixels shorter than the bonobo-window
Comment 4 Christian Neumair 2003-01-29 20:14:49 UTC
Even more obscure:
Different methods of producing UI output (glade, bonobo, plain gtk)
all produce different toolbars. Maybe the containers containing the
child widgets take up some space. I'm not a UI expert, so don't take
me at my word.

Comment 5 Christian Neumair 2003-01-29 20:16:58 UTC
Created attachment 13926 [details]
bonobo (MrProject), glade (Glade), plain GTK+ (gtk-demo) [from left to right]
Comment 6 Hongli Lai 2003-02-02 10:42:38 UTC
Created attachment 14035 [details] [review]
Patch to remove the 1 extra pixel Glade toolbar space. I haven't figured out how to make the toolbar bigger though.
Comment 7 Hongli Lai 2003-02-02 11:45:15 UTC
Created attachment 14036 [details] [review]
Patch to fix Glade's own toolbar.
Comment 8 Damon Chaplin 2003-02-05 23:31:12 UTC
I don't think this is a Glade problem. I think it is basically a bug
in GTK+ which GNOME and Bonobo work around in different ways -

gnome_app_add_toolbar() sets the border width of the toolbar:

	gtk_container_set_border_width (GTK_CONTAINER (toolbar), 1);

In Bonobo, create_dockitem() in bonobo-ui-sync-toolbar.c sets the
border width of the dock item:

	gtk_container_set_border_width (GTK_CONTAINER (item), 2);

The GTK+ toolbar bug is that in the prelight state the buttons are
drawn by default over the toolbar's shadow, which is wrong.
(I looked at it once. I think there are even other related bugs in
GtkHandleBox or something similar as well.)

So you first need to fix GTK+, then change GNOME and Bonobo so they
don't set the border width.
Comment 9 James Henstridge 2003-02-06 01:28:25 UTC
According to owen, this behaviour is "correct" (drawing the buttons
over the bevel).

During 2.0 development, the toolbar was taking the bevel into account
to calculate the height and width, but then positioning the children
incorrectly.  I submitted a patch to fix up the child positioning
which got rejected, and the toolbar was switched to ignore the
thickness of the bevel ...  For those interested, the details are
available in bug 58615
Comment 10 Damon Chaplin 2003-02-06 21:25:23 UTC
OK. Then someone should bring this up with the UI people so everyone
agrees on common spacing in toolbars.

Unless someone shows me evidence that Glade is involved in the problem,
we can close this as NOTABUG.
Comment 11 Ali Akcaagac 2003-02-06 22:13:05 UTC
Hi, I quickly stepped over reading your replies and liked to add
something here.

I was experimenting with these things the past days, made a GTK+
Window and added a normal Toolbar to it and the spacing around it
seems to be correct like the one in Bonobo-Window. Only the Gnome-UI
stuff is broken somehow. Even when using GLADE to make either a GTK+
Window + Toolbar it creates exactly sized Toolbars only when using it
in Gnome-UI mode it breaks the Toolbar. I was talking about this in
the #gnome-de channel and 'herzi' told me that he talked with dom and
dobey about this and that the issues start to come from Gnome-UI and
therefore it's likely to be inherited by GLADE as well. I'm not 100%
sure if I'm right here with what I say but take it as is for the moment.

Even when I take GLADE and generate a *.c code then this +1 border is
placed inside the code.

For the moment I would appreciate if you can leave this BUG open until
a clear solution has been found otherwise we close it and ignore it
for the rest of the time and nothing will ever happen with it anymore.
We should really close a bug until it's absolutely proven that it is
NO bug not earlier.

That's my opinion. I also like to encourage you to write a Mail to the
ML and have a conversation with the individuals that work on such code
so we can find an agreement.
Comment 12 Alex Duggan 2003-02-06 22:19:57 UTC
CC'ing usability
Comment 13 Christian Meyer 2003-02-07 01:18:29 UTC
Hi Damon!

I'm not someone he always agrees to people, but I think oGo is right.
Unless the bug isn't fixed/people haven't figured out where the
problem comes from, the bugreport shouldn't be closed in any way.
Just my humble opinion.
Comment 14 Mirco Müller 2003-02-07 01:51:04 UTC
Whatever is done regarding this issue I hope the Gnome HIG is most
strictly followed. This obvious inconsistency resulting from various
UI-creation tools/paths indicates, that there is still some clean
scheme missing.

Just my 2/100.
Comment 15 Damon Chaplin 2003-02-08 13:33:12 UTC
christian: yes, I think it would be good to fix it. You could move it
to HIG or something so they take a look at the issue.

I think my description of the problem above is correct. It fits in with
all the attached screenshots. So we know what the problem is caused by.
We just need the UI people to say which is correct - GTK+/GNOME/Bonobo.
Comment 16 Christian Meyer 2003-02-09 19:47:12 UTC
Hi Damon!

I'll discuss that with the Usability people. Thank you for your reply.
Comment 17 Calum Benson 2003-02-10 20:14:05 UTC
Weelll... just my humble opinion, but to me the bonobo appearance
looks best.  The icons seem to sit a bit too near the bottom of a gtk
toolbar, and the extra white line in the gnome one is clearly iffy :)
Comment 18 Rodney Dawes 2003-02-15 18:27:20 UTC
Please see bug 55393 as it seems to be the propery place for this bug.
It has a patch attached to it which fixes this problem in GtkToolbar,
where it actually exists. This bug really has nothing to do with
glade, other than the fact that GtkToolbar is broken. My patch also
removes the shadow_type style property, as I believe this should be
something that is themed in the engine, not in the gtkrc. This bug
should probably be marked as a duplicate of 55393.
Comment 19 Rodney Dawes 2003-02-17 18:47:15 UTC
OK, bug 55393 is for 2.3/4 api changes for the tool/menu/dock widgets.
hp requested that I open a new bug for the 2.2.x fixes. There are
several bugs for that. I'm going to turn this into the parent bug and
make it depend on the 3 new bugs I file.

The 3 issues are as follows:

1) Handlebox draws boxes with -1 width/height, even though it gets the
height/width of the widget. This can cause ugliness.

2) The GtkToolbar draws boxes with offsets based on border_width. This
causes the wierd issue people see in glade-generated apps or anything
that uses GnomeUIInfo or plain GtkToolbar.

3) Icon packing in buttons appended to a GtkToolbar is wrong, so
things aren't being centered properly.

Changing information on this bug to reflect it's new status.
Comment 20 Rodney Dawes 2003-02-17 19:01:07 UTC
Adding the 3 bugs that block this bug.
Comment 21 Rodney Dawes 2003-02-17 20:13:46 UTC
Adding a fourth bug which should block this one, which affects
libgnomeui. A patch is attached to it as well.
Comment 22 Rodney Dawes 2003-02-18 01:29:42 UTC
Add the bonoboui bug I just submitted also. Makes everything match
even more perfectly.
Comment 23 Christian Meyer 2003-02-18 11:25:29 UTC
put myself on CC:
Comment 24 Christian Fredrik Kalager Schaller 2003-02-18 22:13:48 UTC
In 55393 Owen says: '*NO* changes to GtkToolbar to improve drawing
will be put into a 2.2.x release. Stable branches are about
bug fixes.'

Considering the importance we are putting on GUI consistency,
useability etc. in the GNOME 2 series I would think issues such as
this should be considered bugs. I mean if the use of different words
for the same action accross the GUI is to be considered a bug then
inconsistent drawing of widgets is definetly also so.
Comment 25 Owen Taylor 2003-02-18 22:22:28 UTC
If there are actually bugs in the code (like the icon packing
problems we fixed prior to 2.2.1), we may get to those.
I haven't looked at the other issues above.

But, no, I don't think changing the drawing of GtkToolbar
in the stable branch is worth spending our limited time on, 
since there are major GtkToolbar changes coming for 2.4;
and any changes made to the old Toolbar on the stable branch
are likely to be simply irrelevant.
Comment 26 Rodney Dawes 2003-02-19 17:52:47 UTC
They are bugs in the code, otherwise they wouldn't be patches to the
code. The code affects how the drawing of the widgets is done, and
this is currently buggy. It only "changes" the drawing of GtkToolbar
in the
sense that it fixes the brokenness of how it is drawn, as it does with
the GtkHandleBox also. I think it is worth spending the time on, as I
did. It took me about 5 minutes to actually write the code, build it,
install it, and make a patch. I fail to see how it would take so long
to look at the 2 lines or so of changes, apply and build if necessary,
and see how much better it looks, would take any longer.

These fixes really should go into 2.2.x releases. I'm sure at least
98% of the people would agree.
Comment 27 Bryan Forbes 2003-03-01 18:19:41 UTC
added myself to CC:
Comment 28 Rodney Dawes 2003-03-02 18:38:19 UTC
Adding usability keyword as the patches for the bugs this depend on
effect the UI slightly and improve UI consistency in the desktop.
Comment 29 Owen Taylor 2003-06-05 23:59:51 UTC
I don't think there is any GTK+ bug here involved (other
than bug 106336, which I just committed a fix for)

The bug here seems to be basically bonoboui and libgnomeui
aren't doing the same thing; I haven't analyzed the details,
but that isn't GTK+'s problem.

The two basic facts that need to be dealt with are:

 - GTK+ defaults to drawing a bevel for GtkToolbar
 - GTK+ draws the buttons _over_ it's bevel by 
   default. (We may revisit this for GTK+-2.4 with
   the new toolbar)

There are multiple things that can be done to avoid
duplicate bevels:

 - Not draw your own bevel
 - Size allocate so GtkToolbar ends up over your bevel
 - Turn of the GtkToolbar bevel; something like:

   gtk_rc_parse_string (
"style \"MyToolbarStyle\" \n"
"  GtkToolbar::shadow-type = none\n"
"widget_class \"*BonoboDockItem.GtkToolbar\" style : highest

Asigning to libgnomeui; I'll let other people fight out who
needs to change.

(The screenshots are all vastly more confusing because they
are done with a custom theme ... it's hard to tell what
are theme bugs, what are bugs that are only revealed with
the custom theme, and what are bugs that would show up
with other themes as well.)
Comment 30 Soren Sandmann Pedersen 2003-07-03 11:09:17 UTC
Created attachment 18000 [details] [review]
Fix to make gnome the best desktop on the planet
Comment 31 Soren Sandmann Pedersen 2003-07-03 11:10:40 UTC
The patch I just attached removes the 2 pixel border that libgnomeui
puts around gtktoolbars. This should take care of any remaining
toolbar drawing weirdness.

Unless someone screams fairly quickly I'll commit it.
Comment 32 Rodney Dawes 2003-07-03 14:13:00 UTC
Soren: GnomeUI used to be setting it to 1 pixel. I made the patch to
make it 2 pixels, to match the bonoboui toolbar size. What you
probably want to do instead, is change the patch so that it sets the
border_width of the BonoboDockItem to 2 pixels instead of the toolbar.
I think this is what was done in AbiWord to make it's toolbar not be
so damn ugly anymore also.
Comment 33 Soren Sandmann Pedersen 2003-07-03 15:05:59 UTC
But that's just workarounds for the problem that your patch to gtk+
fixed. With the latest stable gtk+, GtkToolbar doesn't draw outside
its allocation, so since there is a 2 pixel border around the toolbar,
you can see both the dock item and the toolbar bevels:

If you change the border width of the dockitem, you'll get 2 pixels of
blank space AND a double bevel.
Comment 34 Rodney Dawes 2003-07-03 15:53:44 UTC
Then I would say the more proper fix is to probably commit the other
half of my patch that Owen refused to commit, which makes the
GtkToolbar shadow_type be GTK_SHADOW_NONE by default. This will get
rid of the double-bevel problem and allow us to keep the 2 pixel
border so that all of the toolbar sizes match properly. Currently we
are just iterating through fixing one thing to break another if we
keep changing the border settings and things like your patch does,
which is wrong. So changing the default shadow type seems like the
most appropriate fix.
Comment 35 Soren Sandmann Pedersen 2003-07-03 16:04:44 UTC
That would break all non-gnome applications.
Comment 36 Soren Sandmann Pedersen 2003-07-04 02:23:56 UTC
Fri Jul  4 04:27:42 2003  Soeren Sandmann  <>

	* libgnomeui/gnome-app.c (gnome_app_add_toolbar): remove setting
	of border width, thus getting rid of double bevels.
Comment 37 Rodney Dawes 2003-07-04 12:21:15 UTC
Reopening this because this causes 106342 to re-appear somewhat.
Rather than being set to 1 pixel, it isn't being set at all, and so
the height of the toolbar is off even more and half the gnome apps
don't match the other half that use bonoboui instead of gnomeui for
toolbar stuff. Maybe we should patch gnome-session to do a
gtk_rc_parse_string () to set GtkToolbar::internal-padding = 2, so
that under gnome, everything looks ok at least, if you want to keep
this "patch" in libgnomeui.
Comment 38 Kjartan Maraas 2003-11-30 20:45:11 UTC
Just making sure this is the longest bugreport in libgnomeui
Comment 39 Alex Duggan 2005-02-01 05:17:01 UTC
Is there any reason this bug should still be open?
Comment 40 Alex Duggan 2005-03-04 05:56:17 UTC
No response -> Closing