See docs and following commits for what it's supposed to do. Let's hope
it fixes the flakiness in tests.

Emit the "changed" signal after 150 msecs, so that searching
through big lists, or doing online searches feels more responsive.

This is something already done in various applications to make
search-as-you type more responsive (gnome-shell, gnome-documents,
gnome-control-center, etc.). The 150 msecs is the value currently
used by gnome-shell, so keep it (invisibly) consistent.

https://bugzilla.gnome.org/show_bug.cgi?id=700229

Now that we're not drawing the GdkWindows by themeselves we need to
propagate into children in the same order as the windows were painted
otherwise apps can't rely on stacking order to overlay children.

This is still not 100% the same as the old behaviour, because we're
treating all windows that are part of a window at the same time (to allow
e.g. opacity groups), and we're only looking at order for the main
windows of a widget. However, this fixes at least the ordering
of the gnome-boxes fullscreen overlay toolbar.

https://bugzilla.gnome.org/show_bug.cgi?id=699970

Instead of making clients inspect the submenu action and decide what
to do based upon that, always request the submenu open and let the
tracker decide what to do.

Allison Karlitskaya authored May 08, 2013 and Jasper St. Pierre committed May 13, 2013

Add a new class, GtkMenuTrackerItem that represents a menu item, to be
used with GtkMenuTracker.

GtkMenuTracker's insert callback now works in terms of this new type
(instead of passing reference to the model and an index to the item).

GtkMenuShell now handles all of the binding tasks internally, mostly
through the use of property bindings.  Having bindings for the label and
visibility attributes, in partiular, will help with supporting upcoming
extensions to GMenuModel.

GtkModelMenu has been reduced to a helper class that has nothing to do
with GMenuModel.  It represents something closer to an "ideal" API for
GtkMenuItem if we didn't have compatibility concerns (eg: not emitting
"activate" when setting toggle state, no separate subclasses per menu
item type, supporting icons, etc.) Improvements to GtkMenuItem could
eventually shrink the size of this class or remove the need for it
entirely.

Some GtkActionHelper functionality has been duplicated in
GtkMenuTracker, which is suboptimal.  The duplication exists so that
other codebases (such as Unity and gnome-shell) can reuse the
GtkMenuTracker code, whereas GtkActionHelper is very much tied to
GtkWidget.  Supporting binding arbitrary GtkWidgets to actions vs.
supporting the full range of GMenuModel features for menu items turns
out to be two overlapping but not entirely similar problems.  Some of
the duplication (such as roles) can be removed from GtkActionHelper once
Gtk's internal Mac OS menubar support is ported to GtkMenuTracker.

The intent to reuse the code outside of Gtk is also the reason for the
unusual treatment of the enum type introduced in this comment.

This adds no new "public" API to the Gtk library, other than types that
we cannot make private due to GType limitations.

Allison Karlitskaya authored May 09, 2013 and Jasper St. Pierre committed May 13, 2013

The shell wants to transplant our GtkActionObserver/GtkActionObservable
code now as well, so change to ""-style #includes there.

Allison Karlitskaya authored May 09, 2013 and Jasper St. Pierre committed May 13, 2013

Rename our internal GActionMuxer, GActionObserver and GActionObservable
classes and interfaces to have names in our own namespace.

These classes were originally intended for GIO but turned out to be too
special-purpose to be useful there, so we never made them public API but
have just been copying them around (without bothering to properly rename
them).  Now that other people will be copying them out of Gtk, it's even
more important to prevent this namespace abuse from spreading further.

Allison Karlitskaya authored May 05, 2013 and Jasper St. Pierre committed May 13, 2013

We were using gtk_menu_item_get_label() from a testcase to determine the
label associated with a menu item.  Future changes to GtkModelMenuItem
will cause this to stop working, so try a bit harder to find a label
inside of the item.

This fixes cross compiling where build system != host system.

https://bugzilla.gnome.org/show_bug.cgi?id=699690

Joe Pea authored May 12, 2013 and Matthias Clasen committed May 13, 2013

Use sentence capitalization for the tooltip on the file system disk under Devices.
https://bugzilla.gnome.org/show_bug.cgi?id=698933

GtkApplicationWindow would only update its list of captured accels
when realizing the window. This meant that keyboard shortcuts added
after the window was realised (for example, added by plugins) would
be non-functional.

Solve this by updating our accels every time the accel map changes,
not only when realizing the window.

https://bugzilla.gnome.org/show_bug.cgi?id=700079

Use header captialization, and shorten the labels a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=698361

Items that act on the selection should not be sensitive if the
selection is empty. This was already the case for the 'Copy file
location' item, but not for the 'Add bookmark' and 'Visit file'
items.
https://bugzilla.gnome.org/show_bug.cgi?id=699104

Carlos Garnacho authored Apr 29, 2013 and Matthias Clasen committed May 12, 2013

Usually, educated GtkContainers' forall() implementation returns children
in an order that's safe for the default draw() implementation in GtkContainer.
So for widgets with some stacking notions (eg. GtkOverlay),
_gtk_widget_find_at_coords() needs to recurse within containers in reverse
order so it finds the topmost widget.

As this function is used in both tooltips and DnD code, this improves behavior
of "floating" widgets wrt those two. This could for example be seen in the
"Transparent" GTK+ demo, where dropping text on the entry results on the text
going to the textview.

https://bugzilla.gnome.org/show_bug.cgi?id=699239

gtk_bin_remove can't handle internal children, so we have
to unset the titlebar widget before chaining up in dispose.

https://bugzilla.gnome.org/show_bug.cgi?id=700054

We were not drawing the content background in the titlebar
area when fullscreen, and were still treating clicks there
as if they were on the titlebar.

We should hide custom titlebars when in fullscreen mode, just
as we do for non-custom titlebars.
https://bugzilla.gnome.org/show_bug.cgi?id=700053

https://bugzilla.gnome.org/show_bug.cgi?id=700007

The macro already exists, so it's better to use it.

https://bugzilla.gnome.org/show_bug.cgi?id=700007

Also removed a bogus FIXME comment which might have been true
a long time ago. Clarification: the "domain" attribute specified
in the builder script overrides any domain previously set with
gtk_builder_set_translation_domain(), so the translation of items
here is perfectly correct and does not need to be fixed.

This hunk of code was lost by accident in the previous commit.

Bring back need_default_size. We need it to preserve this
documented behavior:

The default size of a window only affects the first time a window is
shown; if a window is hidden and re-shown, it will remember the size
it had prior to hiding, rather than using the default size.

With this patch, all of the window sizing tests in
gtk/tests/window pass again.

It's not used anywhere outside of gtksizerequest.c anymore.

gtk_widget_preferred_size() is only useful if you want to quickly port a
widget from GTK2 sizing code to GTK3 but does not properly work with
height-for-width as used in GTK. So we don't want to encourage people to
use it. In particular we want people to convert to height-for-width
before adding baseline support to their widgets.

Otherwise we write an empty file, which is lame.

Otherwise we fail when the user doesn't have ~/.config yet.

It's unused and was only useful when perl wasn't installed. But perl is
a dependency of glib these days, so it's useless.

GtkMenu calls gtk_widget_size_allocate on its GtkWindow during
gtk_menu_popup_for_device if the menu has not been realised. This can cause the
allocation of the GtkWindow and the size of the GdkWindow to become out of sync
because a top level GtkWindow does not attempt to re-size the GdkWindow when
its allocation is set.
https://bugzilla.gnome.org/show_bug.cgi?id=695120

Allison Karlitskaya authored May 08, 2013 and Matthias Clasen committed May 09, 2013

always_show_toggle was always set to TRUE in _init() and never changed
from anywhere else.  Remove it and remove the if() statements based on
it.

https://bugzilla.gnome.org/show_bug.cgi?id=699929

Change from gint to gboolean.

This was inadvertedly broken in commit
44ba5d25.
Thanks to Matthew Francis for tracking this down and providing
a fix in https://bugzilla.gnome.org/show_bug.cgi?id=699901