Created attachment 13855 [details]
download this screenshot and zoom in to 400% and look at the circled areas.

Created attachment 13856 [details]
yelp's toolbar magnified with xmag

Upon further examination, it appears that the toolbars in these glade
generated apps are a few pixels shorter than the bonobo-window
counterparts.

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.

regs,
 Chris

Created attachment 13926 [details]
bonobo (MrProject), glade (Glade), plain GTK+ (gtk-demo) [from left to right]

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.

Created attachment 14036 [details] [review]
Patch to fix Glade's own toolbar.

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.

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

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.

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.

CC'ing usability

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.

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.

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.

Hi Damon!

I'll discuss that with the Usability people. Thank you for your reply.

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

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.

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.

Adding the 3 bugs that block this bug.

Adding a fourth bug which should block this one, which affects
libgnomeui. A patch is attached to it as well.

Add the bonoboui bug I just submitted also. Makes everything match
even more perfectly.

put myself on CC:

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.

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.

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.

added myself to CC:

Adding usability keyword as the patches for the bugs this depend on
effect the UI slightly and improve UI consistency in the desktop.

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"
"}\n"
"widget_class \"*BonoboDockItem.GtkToolbar\" style : highest
\"MyToolbarStyle\"");

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

Created attachment 18000 [details] [review]
Fix to make gnome the best desktop on the planet

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.

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.

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:

        http://www.daimi.au.dk/~sandmann/pictures/gnumeric.png

If you change the border width of the dockitem, you'll get 2 pixels of
blank space AND a double bevel.

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.

That would break all non-gnome applications.

Fri Jul  4 04:27:42 2003  Soeren Sandmann  <sandmann@daimi.au.dk>

	* libgnomeui/gnome-app.c (gnome_app_add_toolbar): remove setting
	of border width, thus getting rid of double bevels.

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.

Just making sure this is the longest bugreport in libgnomeui

Is there any reason this bug should still be open?

No response -> Closing