We currently replay events that should start a search to the search
entry, which is fairly dodgy. Synthesize a new event with the correct
source actor instead, which is a bit less evil.
Starting keynav into the active page is handled from a key-press
handler on the stage, however we should not "start" keynav when
we are already navigating elsewhere - the latter can happen when
keynav fails (for instance because the focus is trapped inside an
open app folder or at the end of the dash), and the event bubbles
up to the stage. So make sure to only handle the event to actually
start keynav, to not interfere with the normal navigation handling.
Thanks to Carlos Soriano <carlos.soriano89@gmail.com> for the
debugging footwork.
https://bugzilla.gnome.org/show_bug.cgi?id=726760
Rather than implement special focus policies like only allowing keynav
when pressing down, simply give the active page key focus when entering
the overview.
This may break stuff, as it's somewhat of a tricky patch to get right.
Testing this one would be super appreciated.
https://bugzilla.gnome.org/show_bug.cgi?id=644306
AppDisplay queues a deferred work to load frequently used apps when the
apps page is loaded. Unfortunately, when the overview is first opened,
all the pages start out visible and then immediately get hidden, so the
deferred work runs immediately after the first overview opening, whether
the user was going to view their frequent apps or not.
Start all pages off as hidden, and rearrange the code so that pages are
only shown when they really need to be.
https://bugzilla.gnome.org/show_bug.cgi?id=712753
The existing provider system is split between a confusing mess of
RemoteSearch, SearchSystem, SearchDisplay, and ViewSelector, partly
because of the vestigal in-shell search system. Move most of the
logic to search.js so it's easier to read.
search.js used to do a lot more, but now that most of the
functionality has been moved to the remote search system,
it doesn't do a lot. Merge searchDisplay.js into it.
It's been broken for quite a bit since we removed Panel.Animation,
and hasn't really ever worked with our new search results. It's also
the only non-remote provider left.
Maybe we'll add it back as a remote provider later, but for now, just
ditch it.
It is expected that the primary and secondary icons in entries
change places in RTL locales. When doing so, the edit-clear
icon must be replaced by an rtl variant too.
http://bugzilla.gnome.org/show_bug.cgi?id=705779
This method, which accepts a .desktop filename, is used to highlight
a specific application in the overview, for example because it has
just been created or installed.
https://bugzilla.gnome.org/show_bug.cgi?id=654086
As we want to eventually track two geometries, we need to rename
our very plain "_x, _y, _width, _height". While we could just prefix
them, I think that stuffing them in an object makes more sense.
At the same time, make the variable and method name more descriptive
by adding such a prefix, as well as a bit of documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=694469
To ensure that we don't recalculate window layouts when zooming
in or out, we need to always pass the full geometry. This will
break window repositioning when we zoom back in; for the purposes
of commit clarity, this breaks this feature for now. It will be
added back soon.
https://bugzilla.gnome.org/show_bug.cgi?id=694469
This is a new, regular keybinding for going to the overview.
The default binding is Super-S, which goes well with Super-A
for going to the application grid.
This is separate from the existing panel-main-menu keybinding,
so that we can keep Alt-F1 opening the main menu in classic mode.
https://bugzilla.gnome.org/show_bug.cgi?id=698251
We recently started to trim leading and trailing whitespace from
the search string, and not to trigger a search when the resulting
string was empty. However we still allow whitespace to trigger
type-ahead-find, so that the key focus is moved briefly to the
search entry and back to the stage, resulting in a disruptive
flickering of the entry.
Fix this by excluding whitespace from triggering type-ahead-find.
https://bugzilla.gnome.org/show_bug.cgi?id=694475
With categories removed, the separation between AllAppDisplay and
ViewByCategories no longer makes sense. Also use this opportunity
to rename the outdated AllAppDisplay to AppDisplay; it will
eventually be used to manage different views.
https://bugzilla.gnome.org/show_bug.cgi?id=694192
If the animation time is not the same for these two, the translation
will be adjusted to the allocation during the tween, resulting in a jump
in the animation.
https://bugzilla.gnome.org/show_bug.cgi?id=694035
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
This is nothing but a middle man, as the view selector already owns
the search system. We want to start being a bit more tricky with what
we do with the search system so that we ignore whitespace, so let's
cut the middle-man out now.
https://bugzilla.gnome.org/show_bug.cgi?id=693458
In the overview, when there is no text in the search entry, this._searchActive
will be set to false. Moving the Clutter.Return code block ensures that
pressing enter in the search field after deleting the characters of a search
will no longer launch the #1 application for the previous search.
https://bugzilla.gnome.org/show_bug.cgi?id=692391
'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.
Based on a patch by Tanner Doshier.
https://bugzilla.gnome.org/show_bug.cgi?id=692454
Since commit 0c807bddaf, the run dialog no longer handles Escape
key presses itself but uses the action key mechanism of modal dialogs.
As the latter uses key-release events, our own handling of the Escape
key runs on key-press.
Fix this by bailing out early if anything has pushed a modal in addition
to the overview (like system modals, looking glass, ...).
https://bugzilla.gnome.org/show_bug.cgi?id=688196
