Anytime we begin dragging an app launcher, ensure the overview elements are
showing. While searching, if an item-drag ends or is cancelled, hide the
overview elements, but don't switch back to windows (which was the old
behavior).
https://bugzilla.gnome.org/show_bug.cgi?id=682050
'active' isn't terribly clear about just what is active; also, make it
private, remove an useless extra object state we were saving, and
refactor some messy code.
https://bugzilla.gnome.org/show_bug.cgi?id=682050
Both WorkspacesDisplay and ThumbnailsBox need to know when windows have been
restacked. Instead of each tracking changes on their own or trying to call
each other, have the overview keep track and do the calculations, emitting
a signal with the result.
https://bugzilla.gnome.org/show_bug.cgi?id=682050
show() and hide() now slide the thumbnails in and out, respectively. The old
show and hide are now _createThumbnails and _destroyThumbnails. We only care
about these thumbnails while in the overview, so create them when entering and
destroy them on exit.
https://bugzilla.gnome.org/show_bug.cgi?id=682050
This is causing more confusion than anything else these days; the DBus
API is properly documented now and that's what people are expected to
use, the rest are implementation details we're not interested in
exposing.
https://bugzilla.gnome.org/show_bug.cgi?id=681797
These are for all search results except apps (and Wanda).
We also simplify a bit the packing of search results, which removes some
ugly code in navigateFocus() where we needed to call
st_widget_navigate_focus() twice, since the grid icon was composed by
two nested boxes, both focusable.
https://bugzilla.gnome.org/show_bug.cgi?id=681797
Display a '+' icon on the provider icon if there are more results that are
hidden. If the provider icon is clicked, ask the provider to launch itself and
perform a search with the current terms.
https://bugzilla.gnome.org/show_bug.cgi?id=681797
When pressing the overlay key three times, things went like this:
* show(), push a modal
* hide(), will pop a modal after hiding is done
* show(), push a modal
Thus, when the showing is done, and then it activated the hiding,
it popped one modal, but not the other. This patch changes things
to be:
* show(), push a modal
* hide(), will pop a modal after hiding is done
* hide(), no-op
That is, mashing the overlay-key when it's showing will always make
it hide, not mashing an odd number of times.
https://bugzilla.gnome.org/show_bug.cgi?id=688589
BoxPointer's API changed to take a BoxPointer.PopupAnimation
enumeration value, but the code was accidentally replaced with
older code when porting the PopupMenuManager code to GrabHelper.
https://bugzilla.gnome.org/show_bug.cgi?id=689954
"toggle" is used when clicking on the source actor. As we don't
actually have a menu, we don't want to actually take any grabs
through the menu system, so make it a no-op rather than have it
toggle the menu state.
https://bugzilla.gnome.org/show_bug.cgi?id=689954
This is necessary for child popups in menus, e.g. while in a combo box,
clicking outside of the user menu should drop the entire menu, but
clicking on the user menu itself should only drop the combo box.
https://bugzilla.gnome.org/show_bug.cgi?id=689109
I have no idea why we used 'event' rather than 'captured-event' before.
'event' has some really strange quirks that came up when porting PopupMenu
to the GrabHelper
https://bugzilla.gnome.org/show_bug.cgi?id=689109
