GtkMenu’s own keynav code, which actually bothers to account for the
layout of items, only happens if columns > 1. So, adding items to 1
column using a reverse loop meant they were placed in the Menu’s list of
children in that order, and because we only have 1 column, Menu passes
keynav up to MenuShell, which doesn’t adjust for the items’ positions.
‘Fix’ that here by adding items in the same order they’ll have when laid
out in the Menu, so keynav does what you’d expect, not the opposite. For
that, it’s simpler just to use gtk_container_add().
Let’s presume users are using add(), attach() with a non-inverted loop,
or attach() with arguments that create 2+ columns and so GtkMenu keynav.
It's too close to the release so we'll keep _set_menu() around, but
deprecate it, pointing to the new API. It will be removed (and the name
reused) before the 3.6.0 release.
https://bugzilla.gnome.org/show_bug.cgi?id=682235
As used in Totem and gnome-contacts. The widget
takes either a GtkMenu or a GMenuModel to construct
its menu, and can be given a parent widget to use to
position the drop-down (as used in GtkMenuToolButton).
https://bugzilla.gnome.org/show_bug.cgi?id=668013
As used in Totem and gnome-contacts. The widget
takes either a GtkMenu or a GMenuModel to construct
its menu, and can be given a parent widget to use to
position the drop-down (as used in GtkMenuToolButton).
https://bugzilla.gnome.org/show_bug.cgi?id=668013