As we use g_slist_prepend for efficiency when building the list
of results before ordering it, we need to make sure we traverse
the list of previous results backwards so that it's built in
the same order.
https://bugzilla.gnome.org/show_bug.cgi?id=693936
When we reset the state of the checked button due to the overview
showing and hiding, block the normal checked callback and immediately
switch to the workspaces page, so that windows seamlessly fade in.
https://bugzilla.gnome.org/show_bug.cgi?id=693974
Set the checked property explicitly. This is because
resetShowAppsButton() will only be used to flip the button state
blocking the page change in a future commit.
https://bugzilla.gnome.org/show_bug.cgi?id=693974
And use it in overviewControls. When we moved this code from overview.js
to overviewControls.js we lost a condition so we now slide in controls
even when going back from the overview, which looks bad.
https://bugzilla.gnome.org/show_bug.cgi?id=693974
Early on, search was based on a list of terms, which was like a set
of tags, in that terms were OR'd, and that order didn't matter. As
such, modifying any one of the terms wouldn't produce new results.
Nowadays, providers take the order into account, so a substring
should only be the case if new terms are added to the end.
https://bugzilla.gnome.org/show_bug.cgi?id=693935
If WindowOverlay.relayout() is called without animation, we must stop
any preexisting animation, otherwise it will continue to run with the
previous parameters and cause the overlay to end up in the wrong position.
https://bugzilla.gnome.org/show_bug.cgi?id=693970
The slideX property controls the allocation of the view selector; since
we now know when there are no visible views from the page-empty signal,
we can use it to set the full slideX for the next page at that time,
allowing the new view to fade in with the right width.
This allows us to use simple x translations for the side components when
switching pages, keeping the noise due to resizes at the minimum.
The slideX resize for now is kept for DnD, and will always be needed for
the thumbnails box when showing the windows page.
https://bugzilla.gnome.org/show_bug.cgi?id=693924
GdkPixbuf is stored in memory as individual bytes, in strict red-green-blue-alpha
order, while cairo image surfaces are stored as 32bits units whose
order depends on the endianess.
It is probably possible to do something better, taking advantage
of cogl and the GL using the actual component order, but for now
it is easier to use the GDK utility to convert the cairo surface.
https://bugzilla.gnome.org/show_bug.cgi?id=693931
If we increment our index variable while looping, this means that
firstNewEvent will be one higher than it should. With a length 1
array, all events will be removed, so this has a cascading effect
that events will not be stored at all.
https://bugzilla.gnome.org/show_bug.cgi?id=693854
NMClient recently got more heavyweight, with a property holding supported
connections. As fully initializing a NMObject is a recursive operation
and requires multiple DBus calls, switch to async initalization for NMClient
and NMRemoteSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=683288
We want to make Tweener short-circuit animations when resources are
constrained, so this is not going to work.
Instead, use a one-second timeout until the seconds left reach zero.
https://bugzilla.gnome.org/show_bug.cgi?id=655746
After moving the dummy source actor, we still have to poke the
boxpointer so that it gets repositioned.
This has always been broken but went unnoticed until now since none of
the commonly used engines currently depend on this method. Thanks to
Mathieu Bridon for pointing it out.
https://bugzilla.gnome.org/show_bug.cgi?id=691902
setCandidates() has too many arguments and setting the orientation
isn't particularly related with it. It might also be useful to switch
orientation without changing the candidates.
https://bugzilla.gnome.org/show_bug.cgi?id=691902
Make it look more like the mockups.
In order to do that we stop using PopupMenu and friends as it doesn't
really buy us anything and just makes it more cumbersome to add the
style classes we need.
https://bugzilla.gnome.org/show_bug.cgi?id=691902
