...unless they are labeled.
To implement this, keep track of the nesting depth of section boxes,
starting from 0 for the toplevel and the submenu ones, and only
insert unlabeled separators if the depth is at most 1.
When the adjustment changes (due to e.g. a mouse wheel scroll) we update
the prelight. The part that un-prelights the previous prelight was
broken by the the pixel cache, as it called update_prelight in the
middle of the scrolling operation, where the windows were moved
but the tree_view->priv->dy was not changed to the new value. This
caused the updates to the pixel cache to go to the wrong place.
We fix this by fully doing the scroll before we update_prelight().
https://bugzilla.gnome.org/show_bug.cgi?id=728284
GtkMenuTrackerItem::visible was removed a few commits ago.
It is not necessary to bind visible anyway, since the menu
tracker will insert and remove items as their visibility
changes.
Rendering doesn't do much about clipping drawing operations to the window shape,
although invalidation applies the shape to every window, leaving possibly trails
of "overrendered" content. So ensure the shape portions get invalidated too when
the window is moved/resized.
https://bugzilla.gnome.org/show_bug.cgi?id=729095
Now that popovers may snap to any side with enough space, make enough
room on every side when requesting size, so that there's no w/h differences
at the time of setting the child allocation.
https://bugzilla.gnome.org/show_bug.cgi?id=729097
When activating an item using mnemonics GtkRecentChooserMenu does not select a
item before calling the item-activated signal thus
gtk_recent_chooser_get_current_uri() always return the last selected item
instead of the activated one.
Fixes Bug 495105 "Open recent file keyboard shortcuts do not work correctly"
The real reason for the problem that the just reverted change
was supposed to address is that testfilechooser uses show_all
to tease out places where composite dialogs don't properly
protect their internals against unintended showing. Well,
lets do that, then.
In iconic mode, model buttons will be styled like regular icon
buttons, preferring to show only the icon if one is set, falling
back to showing the label.
https://bugzilla.gnome.org/show_bug.cgi?id=727477
When rendering iconic sections, we want to use icons for verbs,
and we want to differentiate these in the menu model, to keep
the icon attribute reserved for nouns.
https://bugzilla.gnome.org/show_bug.cgi?id=727477
Instead of using GtkMenuTracker to flatten the sections into a single
linear menu, handle the sections ourselves by nesting boxes.
Each section gets an inner and outer box. The inner box numbers its
children in the way that the tracker instructs. The outer box
containes the inner box and the separator, if appropriate.
Having the two separate boxes will allow us to change the orientation of
the inner box if we want to pack widgets horizontally within a section.
Add the possibility of a GtkMenuTracker that performs no section
merging. Instead, it will report an item in the form of a separator for
subsections. It is then possible to get a separate tracker for the
subsection contents by using gtk_menu_tracker_new_for_item_link().
We have some API in GtkMenuTracker and GtkMenuTrackerItem that is
specifically designed to deal with submenus.
Generalise these APIs to take a 'link_name' parameter that we always
give as G_MENU_SUBMENU for now. In the future, this will allow creating
trackers for other types of links, such as sections.
Make this a property just like all of the other things and make the APIs
for accessing it non-private (but add a note that they are not intended
to be used).
This is not a great name to use in themes; instead, add the
menuitem class, so themes can use .button.menuitem for styles
that are specific to menuitem-like buttons.
We were not really handling all cases correctly here. We want
the suggested-action style class to only be set on headerbar
buttons, and it should be set on the default widget. Ensure
this by syncing the suggested-action style class with the
default style class. As a side-effect, setting has-default
on an action widget in ui files will now have the expected
effect.
https://bugzilla.gnome.org/show_bug.cgi?id=728846
GtkDialog has convenience API for adding action widgets that are
either placed in the action area or the headerbar. This commit
makes the same functionality available from GtkBuilder ui files
by specifying "action" as the child type.
https://bugzilla.gnome.org/show_bug.cgi?id=728846
