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 106336 - GtkToolbar draws with offset of border_width
GtkToolbar draws with offset of border_width
Product: gtk+
Classification: Platform
Component: Widget: Other
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
: 106335 (view as bug list)
Depends on:
Blocks: 104549
Reported: 2003-02-17 18:56 UTC by Rodney Dawes
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---

Patch to fix GtkToolbar paint_box bug (733 bytes, patch)
2003-02-17 18:56 UTC, Rodney Dawes
none Details | Review
Screenshot showing the faulty toolbar border (17.78 KB, image/png)
2003-03-29 20:31 UTC, Marc Maurer

Description Rodney Dawes 2003-02-17 18:56:36 UTC
GtkToolbar is currently calling paint_box with offsets for border_width,
which is wrong, and makes the toolbar look very ugly.

Attached is a patch to make GtkToolbar draw correctly and fix this bug.
Comment 1 Rodney Dawes 2003-02-17 18:56:59 UTC
Created attachment 14391 [details] [review]
Patch to fix GtkToolbar paint_box bug
Comment 2 Owen Taylor 2003-02-27 21:18:10 UTC
What it does currently looks perfectly correct to me.

Why do you think it is incorrect?
Comment 3 Rodney Dawes 2003-03-02 18:34:04 UTC
It causes too many bevels to be drawn and doesn't behave correctly in
most cases, and looks horrid. If you remove the border_width offsets,
it looks 1000x better, border_width is still taken into account for
the widget, so the spacing is correct, rather than having the buttons
be the full height of the bevel area. It is also now consistently
drawn as the bonobo toolbar is, and so everything matches nicely and
the desktop is consistent as it should be. Shadow types other than
SHADOW_OUT still work and look better as well (especially with the
Handlebox patch I've submitted in bug 106335 applied also). Please
commit these patches. I will also have a patch for MenuBar submitted
soon as well, as it has similar issues, most noticeable when embedding
a menubar in a handlebox.
Comment 4 Rodney Dawes 2003-03-03 03:44:29 UTC
*** Bug 106335 has been marked as a duplicate of this bug. ***
Comment 5 Rodney Dawes 2003-03-04 03:18:09 UTC
--- gtk+-2.2.0.orig/gtk/gtktoolbar.c	Sat Feb 15 10:32:03 2003
+++ gtk+-2.2.0/gtk/gtktoolbar.c	Mon Feb 17 13:43:36 2003
@@ -557,10 +557,10 @@
                      GTK_WIDGET_STATE (widget),
 		     &event->area, widget, "toolbar",
		     widget->allocation.x + border_width,
                     widget->allocation.y + border_width,
-		     widget->allocation.width - border_width,
-                     widget->allocation.height - border_width);
		     widget->allocation.x + border_width,
                     widget->allocation.y + border_width,
+		     widget->allocation.width - border_width * 2,
+                     widget->allocation.height - border_width * 2);
       for (children = toolbar->children; children; children =

Owen: This may be a better patch to your liking, GtkMenuBar needs
the same fix to it's call to gtk_paint_box (). The problem is that you
are only subtracting what you're adding, so the toolbar is still
drawing over top of the handlebox on the bottom/right edges. The extra
pixel hangoffs occur from the border_width and is the number of pixels
that this is set to. If this patch is to be applied, rather than the
first one, can we also change the default shadow_type to be
GTK_SHADOW_NONE so that it at least doesn't look like crap by default,
since the handlebox defaults to GTK_SHADOW_OUT? Pick which one patch
you would rather commit to fix this bug, and I'll make a patch for
GtkMenuBar also, and update the libbonoboui patch I made, to do the
exact same thing. However, the best solution with this second patch is
to make the default shadow be SHADOW_NONE. Thanks.
Comment 6 Marc Maurer 2003-03-29 20:31:07 UTC
Created attachment 15303 [details]
Screenshot showing the faulty toolbar border
Comment 7 Marc Maurer 2003-03-29 20:31:28 UTC
In response to Owen's question: "What it does currently looks
perfectly correct to me. Why do you think it is incorrect?"

Have a look at the attached screenshot of Abiword for GTK2. I think
it's obvious that the toolbar does indeed have too many bevels.
Comment 8 Owen Taylor 2003-03-30 00:38:14 UTC
it's irrelevant to me that abiword has too many bevels.
That simply isn't GTK+'s problem, and we can't go changing
the the behavior of GTK+ in the middle of a stable
Comment 9 Owen Taylor 2003-03-30 00:39:21 UTC
(I think Rodney's Dawes last patch is correct, and I'll
likely apply that for 2.2.2, but I'm not changing the 
Comment 10 Rodney Dawes 2003-03-30 05:05:22 UTC
Can I commit the last patch and another that fixes the same thing in
GtkMenuBar so that everything is consistent and the offset math bugs
are fixed? Thanks.
Comment 11 Rodney Dawes 2003-05-27 21:03:13 UTC
Hello? Is that an approval to commit the toolbar patch?
Comment 12 Owen Taylor 2003-06-04 23:18:29 UTC
Two questions: 

 - GtkMenuBar has the same bug? Where?

       gtk_paint_box (widget->style,
                     GTK_WIDGET_STATE (widget),
                     get_shadow_type (GTK_MENU_BAR (widget)),
                     area, widget, "menubar",
                     border, border,
                     widget->allocation.width - border * 2,
                     widget->allocation.height - border * 2);
 - Who sets the border_width on a toolbar? While I'll fix
   the bug, I can't imagine it will change the appearance
   of any applications.
Comment 13 Owen Taylor 2003-06-05 23:39:42 UTC
OK, after some discussion with Soeren, we reverse-engineered
that BonoboDockItem sets the border-width because in GTK+-1.2
that worked to make GTK+ not overlap toolbar buttons over the
toolbar bevel. 

Thu Jun  5 19:24:33 2003  Owen Taylor  <>
        * gtk/gtktoolbar.c (gtk_toolbar_expose): Subtract off
        twice the border width from the width/height, not
        1x the border width. (#106336, Rodney Dawes)