Created attachment 14390 [details] [review]
Patch to fix the paint_box bug in GtkHandleBox

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.

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
http://www.gtk.org/~otaylor/gtk/2.0/theme-engines.html .

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.

Created attachment 14703 [details]
Broken default drawing of handlebox

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

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.

Created attachment 14712 [details]
Drawing with patches applied

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.

Created attachment 14713 [details]
Broken paint_box call in handlebox

Created attachment 14714 [details]
Fixed paint_box call in GtkHandlebox

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.

Is that the default theme engine in your screenshots? No.
How is that going to prove that it isn't an engine bug???

Attachment 14703 [details] is the default gtk engine, yes.

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.

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.

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