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 106335 - GtkHandleBox calls paint_box with wrong width and height
GtkHandleBox calls paint_box with wrong width and height
Status: RESOLVED DUPLICATE of bug 106336
Product: gtk+
Classification: Platform
Component: Widget: Other
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Depends on:
Blocks: 104549
Reported: 2003-02-17 18:52 UTC by Rodney Dawes
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---

Patch to fix the paint_box bug in GtkHandleBox (690 bytes, patch)
2003-02-17 18:53 UTC, Rodney Dawes
none Details | Review
Broken default drawing of handlebox (1.70 KB, image/png)
2003-03-01 01:39 UTC, Rodney Dawes
Drawing with patches applied (8.82 KB, image/png)
2003-03-01 16:08 UTC, Rodney Dawes
Broken paint_box call in handlebox (2.16 KB, image/png)
2003-03-01 18:30 UTC, Rodney Dawes
Fixed paint_box call in GtkHandlebox (1.86 KB, image/png)
2003-03-01 18:32 UTC, Rodney Dawes

Description Rodney Dawes 2003-02-17 18:52:41 UTC
GtkHandleBox is calling gtk_paint_box () with a height and width of -1.
This causes ugliness with GtkToolbar::shadow-type = GTK_SHADOW_NONE

Attaching a patch to fix this.
Comment 1 Rodney Dawes 2003-02-17 18:53:52 UTC
Created attachment 14390 [details] [review]
Patch to fix the paint_box bug in GtkHandleBox
Comment 2 Owen Taylor 2003-02-27 21:24:00 UTC
Current code looks perfectly correct to me. Theme engines
must treat -1, -1 as "width and height of the drawable".

Probably a theme engine bug.
Comment 3 Rodney Dawes 2003-03-01 01:38:44 UTC
My engine does use the w/h of the drawable if the sizes are -1. Why
shouldn't it be passing the width/height to the paint_box call
properly? Currently as-is, all themes are broken, unless they do
manual compensation somehow. The default gtk+ drawing code is broken also.
This patch fixes all occurances of this. I see no reason to pass -1 in,
that is just silly. Is this documented anywhere either? It doesn't
seem to be documented in .

Attaching a screenshot of broken default drawing of Handlebox in gtk+.
Notice the extra pixel on the bottom right of the box for the widget.
Comment 4 Rodney Dawes 2003-03-01 01:39:23 UTC
Created attachment 14703 [details]
Broken default drawing of handlebox
Comment 5 Owen Taylor 2003-03-01 02:51:43 UTC
gtk_default_draw_box (GtkStyle      *style,
                      GdkWindow     *window,
                      GtkStateType   state_type,
                      GtkShadowType  shadow_type,
                      GdkRectangle  *area,
                      GtkWidget     *widget,
                      const gchar   *detail,
                      gint           x,
                      gint           y,
                      gint           width,
                      gint           height)
  gboolean is_spinbutton_box = FALSE;

  g_return_if_fail (GTK_IS_STYLE (style));
  g_return_if_fail (window != NULL);

  sanitize_size (window, &width, &height);


What do you think sanitize_size() does? My tutorial 
on theme engine writing is in no way authoritative
or complete.

[ Actually, -1,-1 isn't quite the same as passing
  in the width/height it also has the additional
  meaning that if the drawable is a window, you
  are allowed to set the background pixmap and/or
  shape-mask for the window. It used to be important
  before almost everything was made NO_WINDOW ]

I can't tell for sure from your screenshot, but it
appears to rather be the contents of the handlebox
drawing over the bevel (perhaps a size allocate 
problem?) rather than anything wrong with the 

In a little experimentation, it appears that 
gtk_handle_box_size_request/allocate() doesn't 
actually leave any space for the shadow between
the child and the bevel of the handlebox. Which
is a little weird, and would explain your 
screenshot if some of the contents were a
widget with a window. But it may be intentional
in order to prevent excessive amounts of bevel,
when you say, put buttons inside a toolbar,
inside a handlebox.
Comment 6 Rodney Dawes 2003-03-01 16:08:43 UTC
Created attachment 14712 [details]
Drawing with patches applied
Comment 7 Rodney Dawes 2003-03-01 16:53:10 UTC
Attached a screenshot with this patch, the GtkToolbar paint_box patch,
and the libbonoboui patch applied (relevent because of eog/gedit in
the screenshot). This looks correct and like what one would be trying
to achieve with the toolbar code.

Yes, I know exactly what sanitize_size () does... Pretty much every
engine in existence has that code copied in, including mine. This is
not an engine bug, so please don't try to pawn it off as one. If the
code is to intentionally avoid excessive bevel, then it is definately
broken as it creates excessive bevel and this and the toolbar patch
must be applied.

If you're tutorial is not authoritative or complete, then what is?
Where in a piece of documentation can I go and see that I need to use
the size from the GdkWindow argument, if the width/height passed in
are -1?

I am going to re-create screenshots with/without the patches, using
the default gtkstyle stuff to prove this.
Comment 8 Rodney Dawes 2003-03-01 18:30:13 UTC
Created attachment 14713 [details]
Broken paint_box call in handlebox
Comment 9 Rodney Dawes 2003-03-01 18:32:18 UTC
Created attachment 14714 [details]
Fixed paint_box call in GtkHandlebox
Comment 10 Rodney Dawes 2003-03-01 18:35:59 UTC
Attached two images which clearly show the broken drawing of
GtkHandlebox. And, NO, this is NOT an engine bug. The exact same thing
happens in gtkstyle.c. The right thing to do is not work around gtk+
bugs in engines. That is even more broken. This is clearly visible
when you set GtkToolbar::shadow-type = GTK_SHADOW_NONE in a gtkrc style.
Comment 11 Owen Taylor 2003-03-01 18:39:45 UTC
Is that the default theme engine in your screenshots? No.
How is that going to prove that it isn't an engine bug???
Comment 12 Rodney Dawes 2003-03-01 18:50:09 UTC
Attachment 14703 [details] is the default gtk engine, yes.
Comment 13 Owen Taylor 2003-03-01 19:27:59 UTC
What I'm saying is that what you _haven't_ proved
is that your patch fixes the problem with the default
theme engine.

But rather than spending your time on that, please explain
how changing -1,-1 to width,height affects
a correct theme engine.
Comment 14 Rodney Dawes 2003-03-01 19:56:17 UTC
In attachments 14703 and 14713 you can see that the top of the
Handlebox has a light_gc line all the way across, and that at the
bottom of the handlebox, there is a dark_gc line that sticks out a
pixel from the
actual box that is the handlebox_bin grab. This is with -1,-1 as the
width, height arguments.

In attachment 14714 [details], you see that this doesn't happen. This is with
width, width height passed as the arguments.

These are with GtkToolbar::shadow-type = GTK_SHADOW_NONE. It is visible
with SHADOW_OUT, but less distinguishable.
Comment 15 Rodney Dawes 2003-03-03 03:44:35 UTC
> I can't tell for sure from your screenshot, but it
> appears to rather be the contents of the handlebox
> drawing over the bevel (perhaps a size allocate 
> problem?) rather than anything wrong with the bevel.

It looks like this is slightly the case, but only happens when the
child is GtkToolbar. I dug even deeper and it seems this isn't the
actual bug, but bug 106336 instead is the one with the patch that
fixes this, and this patch does nothing. Sorry.

*** This bug has been marked as a duplicate of 106336 ***