I can't test right now, but what I would suggest is to check what you are doing against what known-working programs do - e.g. this test from GTK+ itself:

https://git.gnome.org/browse/gtk+/tree/tests/testtoolbar.c?h=gtk-3-22

You should be able to compile that as a single file, after first commenting-out the #include "config.h"

I tested it, and it does reveal the arrow once resized down, on latest GTK+ 3.22, so the feature is not inherently broken: we just need to ascertain why it shows there but not for your code.

Picking out the relevant bits to compare between your code and that, maybe you'll figure it out before anyone else does. If so, let us know what you find out!


(also, just to let you know, as the reporter you'll always get an email, even if you don't specifically add yourself to the CC list, so don't worry about that)

A little check into gtktoolbar.c reveals the logic it uses for its decision:

          /* Do we need an arrow?
           *
           * Assume we don't, and see if any non-separator item
           * with a proxy menu item is then going to overflow.
           */
          if (needed_size > available_size &&
              !need_arrow &&
              priv->show_arrow &&
              toolbar_content_has_proxy_menu_item (content) &&
              !toolbar_content_is_separator (content))
            {
              need_arrow = TRUE;
            }


toolbar_content_has_proxy_menu_item() does this:

 GtkWidget *menu_item;

  if (content->has_menu == YES)
    return TRUE;
  else if (content->has_menu == NO)
    return FALSE;

  menu_item = toolbar_content_retrieve_menu_item (content);

  content->has_menu = menu_item? YES : NO;

  return menu_item != NULL;


which makes sense: the documentation talks about an "overflow menu", so you need to be adding menu items in order for them to be able to overflow, via the arrow.

As that hints, if you want any other item to be able to overlow, just call gtk_tool_item_set_proxy_menu_item():

https://developer.gnome.org/gtk3/stable/GtkToolItem.html#gtk-tool-item-set-proxy-menu-item

> Sets the GtkMenuItem used in the toolbar overflow menu.

So I guess this is "NOTABUG", too... :)

You can also decide dynamically whether to create a proxy menu item, using the ToolItem::create-menu-proxy signal:

https://developer.gnome.org/gtk3/stable/GtkToolItem.html#GtkToolItem-create-menu-proxy

That ultimately needs to just call set_proxy_menu_item() to set or clear the proxy, but it means you can update whether/which item to show as you go along.


> So I guess this is "NOTABUG", too... :)

though it's probably worth improving the documentation on the GtkToolbar side; it doesn't mention any requirements on which ToolItems can appear in the overflow menu, so that has to be pieced together in the way I've done here: by just looking at the Toolbar source, or by noticing the stuff about proxy menu items in the ToolItem documentation and putting 2 and 2 together.

Thanks for this fast investigation! Yes, it would be great to have this info in the official documentation!

Another possibility to lead the programmer the right way:
If there is no menu-item and an arrow should be shown --> How about to print some warning in order to signal that a menu-item is missing ?

The documentation side should be nice and simple. This, however:

(In reply to alexxcons from comment #5)
> Another possibility to lead the programmer the right way:
> If there is no menu-item and an arrow should be shown --> How about to print
> some warning in order to signal that a menu-item is missing ?

How should it know it "should" show an arrow? i.e. How is it meant to distinguish between items that aren't important and so should be ignored for the menu (like a cosmetic Label), versus items the user really wants in the menu but has forgotten to provide a proxy menu item? That seems like it might require psychic powers...

related: How can we ensure this proposed new warning doesn't start appearing in lots of cases where it shouldn't, and really annoying existing Toolbar users?

(In reply to Daniel Boles from comment #6)
> The documentation side should be nice and simple.

I think these should suffice:

https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22&id=66d63e4a4702df0f340179dc847fae19e49ddab8
https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-22&id=8dbb17e1f3bebd469afb59a82b29b78b9f6873bd

I'm going to close this one, but if you come up with a comprehensive model by which your idea of a warning can work, you're welcome to submit an enhancement request... though someone else may just want to close it immediately. :P

Yes, looks like a warning is not possible that easy. One could think about something like:
For tool-items which should not show up in the menu, one has to mark them explicitly by e.g. gtk_tool_item_no_proxy_menu_item()

.. but actually telling a widget that it should "not" do something, smells like bad design.

So here a proposal for a completely different approach:
https://bugzilla.gnome.org/show_bug.cgi?id=787224

(In reply to alexxcons from comment #8)
> One could think about something like:
> For tool-items which should not show up in the menu, one has to mark them
> explicitly by e.g. gtk_tool_item_no_proxy_menu_item()

This doesn't make sense. Either the subclass (e.g. ToolButton) or the user has to specify what the proxy menu item will be. You can't just say 'other widgets should show in the overflow menu unless told not to', because there is no mechanism by which they can show, without a menu item. And GTK+ can't guess what kind of menu item you want for arbitrary widgets, or what activating it should do.