GitLab

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

Change "Englihs" to "English"
Change "Page up" to "Page Up"
Change "Page up (keypad)" to "Page Up (keypad)"
Change "Page down" to "Page down"
Change "Page down (keypad)" to "Page Down (keypad)"

This is a reorganization of the testsuite to be in the testsuite/
directory, so it can be installed from there.

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

We don't track the full clip for each window anymore, as this
is not useful when no windows are opaque. However, we still
need the full clip for the shape, so its calculated manually.

However, it was previously only recalculated when the clip changes
which doesn't correctly handle the case of a sibling geometry changing.

So, instead of doing this directly when geometry changes we just
set a bit in the toplevel whenever some window geometry changes, and
we then handle this in process_updates, updating the shape for all
native windows. This should be ok performance-wise because we don't
expect a lot of native children.

We keep a list of all native children of a native window. This means
we don't have to recurse over the entire hierarchy to find any
native children.

This will be used to tell it where its test data resides
when running the a11y tests installed.

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

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 reverts commit 99c7091a.

Please, no more touching of POTFILES.in without asking first.
These .ui.h files are really meant to be there.

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

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