Note from Jim Cape on how to do tearoff menubars:

Actually, tearoff menubars as they exist now are useless. I've
recommened repeatedly that when they are torn off they become NeXT-style
pinned menus (or torn-off menus). IOW, a system similar to this:

[# File Edit Blah Help ]
  -----(torn-off)-----
=================
|     File    > |
|     Edit    > |
|     Blah    > |
|     Help    > |
| [_] Re-attach |
-----------------

Doing something like that couldn't be all that difficult.

    Jim Cape
    http://www.ignore-your.tv

*** Bug 53028 has been marked as a duplicate of this bug. ***

*** Bug 74329 has been marked as a duplicate of this bug. ***

James Hensstridge has done some work on this:
http://mail.gnome.org/archives/gtk-devel-list/2001-December/msg00039.html

I'd started looking at it and had nearly the same setup. I don't
think this should be particular to menu items. I'm also wondering
if it would be useful to have non-GUI actions - maybe for scripting.

Something missing from versions I've seen is an tooltip for when the
action is not available - i.e., when the widget is insensitive. This
is blocked by insensitive widgets not being able to display tooltips.

Another problem is dynamic items such as Undo/Redo. It's considered
better UI, afaik, to indicate what will be undone or redone. Related
to that are dynamic tooltips, though I've not seen mention of them
anywhere - a back button on a browser might display a URL in a
tooltip. Perhaps a printf-like string should be supported. A
way to quickly change the visible string should be useful for
programs like Nautilus which would like to display Cut/Copy/Paste
information when the menu is shown.

Something that seems indispensible to me is a long description of
an action. This would be like what apropos provides in lisps.
(OTOH, why don't we all just use lisp. :-)

Another thing to look at is stock actions. Somehow a way for
one program to use actions from a pool of actions would be useful;
it would be a sort of library, but visual - this seems really
far-fetched from now. (VisualLisp? eek.)

Bug 82869 asks for the ability for the user to be able
to interactively customize toolbars.

*** Bug 82869 has been marked as a duplicate of this bug. ***

Bug 75068 suggest to support GtkToolbar.set_homogeneous with GtkSizeGroup.
and has a rough patch without GtkSizeGroup.

Move bugs which are tracking planned 2.4 features to the proper target
milestones.

*** Bug 50367 has been marked as a duplicate of this bug. ***

I have a patch to make GtkToolbar draw the same as the
BonoboUIToolbar. It makes everything look much nicer. Can we please
get this in a 2.2.x release or somewhere along the line? Thanks, patch
attached below.

Created attachment 14353 [details] [review]
Patch to fix drawing of GtkToolbar to look better and be consistent with BonoboUIToolbar (when embedded in a GtkHandleBox)

I somehow doubt that ignoring borderwidth is considered an 
improvement...and 
drawing outside of the allocation doesn't look too nice either.

Created attachment 14356 [details] [review]
Revised Patch to fix drawing of toolbars

Attached a revised patch. This one just removes the paint_box call and
shadow_type property entirely. I can see no usefulness for the
shadow_type property. If the shadow_type gets changed, it should
probably be done by the gtk+ engine and not with a style property.

As for the removal of border_widget in the previous patch... it should
not be used to determine the box size of the actual widget, as the
higher you set the border width, the further right/down the x/y move,
so you get a really ugly toolbar. As for drawing outside of the
allocation,
I don't think the paint_box call and shadow_type property are
necessary at all anyway. Feel free to provide a counterpoint to prove
that wrong.

Created attachment 14389 [details] [review]
Patch to fix icon packing so that icons are centered vertically

Attached a patch to fix icon packing, so that the icons are centered
vertically, and match the BonoboUIToolbarButtonItem behavior. Can we
at least get this into a 2.2.x release? It would make at least the icons
look more consistent.

If there's going to be lots of discussion of the 2.2.x patch can 
we please open a new bug report? Already it's swamping discussion 
of the new toolbar API on this report.

*NO* changes to GtkToolbar to improve drawing will be
put into a 2.2.x release. Stable branches are about
bug fixes.

Sorry hp. I've filed 3 new bugs with patches that take care of the 3
separate issues that exist with GtkToolbar and GtkHandleBox. There was
previously a bug filed against glade about the main toolbar issue,
which I have subsided into a metabug for the 3 others. See bug 104549
for the 2.2.x Toolbar/HandleBox issues. Thanks.

The new toolbar code and the action-based menu code from libegg have


been integrated now. Whats left in this bug seems to be 




a) interactive toolbar customization (toolbar editor)


b) better handling of detached toolbars/menubars




I've filed separate new bugs for these, bug 120645 and bug 120646.


Closing this one.