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
The top panel and message tray icons were by default a gnome foot and
are replaced by better ones. The applications icon is now using the
symbolic apps icon of the dash, and the windows icon is also improved.
https://bugzilla.gnome.org/show_bug.cgi?id=641303
This is a workaround for power users for the "Show Apps" button
placement being too inconvenient to press at the bottom of the
dash favorites list.
Unity also uses Super+A to show the Apps lens.
https://bugzilla.gnome.org/show_bug.cgi?id=685738
Remove the PlacesManager, its search provider and all associated code.
Places search is now provided by nautilus using the external search
provider API.
https://bugzilla.gnome.org/show_bug.cgi?id=683506
Since we now use the capture phase to feed events into the input
method, we must set the capture flag for the event that starts
searches so that IMs can get at it.
https://bugzilla.gnome.org/show_bug.cgi?id=684040
With the latest changes to the overview, the application view is now
clearly on a different level compared to the window picker. For that
reason it now makes sense to close it on Escape rather than hiding
the overview directly, as we do for search.
https://bugzilla.gnome.org/show_bug.cgi?id=682109
Rather than relying on implementation details of StWidget's keyboard
navigation to "hide" the focusTrap from arrow key navigation, implement
the desired behavior explicitly in a custom widget.
https://bugzilla.gnome.org/show_bug.cgi?id=663901
Tabs used to provide an abstraction for a page and the control used to
activate it. As the latter has now been replaced with external controls
handled directly in the viewSelector, the abstraction itself doesn't make
much sense anymore. In preparation of replacing it, move the search
handling provided by the SearchTab directly in the viewSelector.
https://bugzilla.gnome.org/show_bug.cgi?id=682109
We pass the dash’s showApps button to the viewSelector, and we connect it
to the showing and hiding of the appsView. This is necessary because there
are different mechanisms for switching the views, and it has to stay in
sync with the button’s state.
https://bugzilla.gnome.org/show_bug.cgi?id=682109
The entry should be positioned in the center of the overview. This makes
that its position can’t be set in the viewSelector without making things
overly complicated. Therefore we move the entry to the overview.
https://bugzilla.gnome.org/show_bug.cgi?id=682109
Design calls for views being accessible by other means than the current tab
system, so we have no longer a need for the public viewTab API. Move the
initialization of tabs to the viewSelector and make
viewSelector.addViewTab() private.
https://bugzilla.gnome.org/show_bug.cgi?id=682109
The original design for the overview had buttons for searching for
Wikipedia and Google, but in practice this is a bad idea. The buttons
are the default activations, meaning that using the overview as a
fluent motion of launching something - "firefxo<Enter>", will launch
Google/Wikipedia.
https://bugzilla.gnome.org/show_bug.cgi?id=670168
We currently require users to tab away from the search entry before
search results can be navigated using arrow keys. For convenience,
support using arrow keys directly from the entry.
https://bugzilla.gnome.org/show_bug.cgi?id=663901
With the recent keynav changes, the keyboard focus can now move
away from the search entry while a search is active. While we
keep the focus entry style while a search is active, we set the
cursor visibility depending on whether the entry has focus. This
doesn't seem very logical, so always request to show the cursor
when we appear focused.
Note that at least for now we are just expressing intent, as clutter
never draws the cursor for unfocused entries.
When canceling a search pressing Escape while the focus is on the
search entry we clear the entry, set its text to the hint and go back
to the previously selected tab. Make this the behavior also for when
the focus is on search results and not on the entry itself.
https://bugzilla.gnome.org/show_bug.cgi?id=663901
WorkspacesDisplay was introduced to manage the workspace objects
and views; however, the overview still accesses the view held
by the workspacesDisplay directly, which is a bit odd.
Add some additional methods needed by the overview, and make the
view a private property.
https://bugzilla.gnome.org/show_bug.cgi?id=652580
The last patch in the sequence. Every place that was previously
setting prototype has been ported to Lang.Class, to make code more
concise and allow for better toString().
https://bugzilla.gnome.org/show_bug.cgi?id=664436
All classes that have at least one other derived class (and thus
benefit from the framework) have been now ported. These includes
NMDevice, SearchProvider, AltTab.SwitcherList, and some other
stuff around.
https://bugzilla.gnome.org/show_bug.cgi?id=664436
Use ShellEntry.addContextMenu() to add context menus to most
existing entries, with the exception of:
- the login dialog - it may act be used to enter either the
username (e.g. no password entry) or the
password, and copy/paste does not make sense
(nowhere to copy from, nowhere to paste to)
- notifications - while adding a context menu is useful here as
well, it will require changes to the tray's
focus grab handling, so leave those entries
out for now
https://bugzilla.gnome.org/show_bug.cgi?id=659275
The keyboard hides prematurely when the user is typing into
an empty search box because the click is a captured event that
triggers a loss of entry focus. By adding a keyboard check to
this event, the problem is solved.
https://bugzilla.gnome.org/show_bug.cgi?id=661340
js2-mode is no longer developed and we recommend js-mode these days,
so switch the modelines to specify that, and make them consistent
across all files.
https://bugzilla.gnome.org/show_bug.cgi?id=660358
As extensions are now expected to provide a "disable" function,
they need to remove search providers they added. Implement the
removal functionality and add a public removeSearchProvider()
method.
https://bugzilla.gnome.org/show_bug.cgi?id=657548
Some search providers may want to change their results, or may not
want to block on an external service to get their results (DBus, etc.)
Set up an infrastructure to allow search providers to add their search
results at a later time.
Based on a patch by Jasper St. Pierre and Seif Lotfy.
https://bugzilla.gnome.org/show_bug.cgi?id=655220
In the current implementation of the search entry, when replacing a
selected search term with another term, the first character of the
replacement is prepended to the hint text rather than starting a new
search. This fix makes sure that the focus is not lost when changing
the selected search term.
https://bugzilla.gnome.org/show_bug.cgi?id=636341
The icon set as secondary icon of the search entry depends on whether
a search is active or not - clicking the icon should reset the entry
only in the former case. This is implemented by connecting/disconnecting
the 'secondary-icon-clicked' signal when updating the icon, but an
additional signal connection was left-over when refactoring the search
entry, resulting in clicks on the inactive icon removing the hint text.
Fix by removing the stray signal connection.
https://bugzilla.gnome.org/show_bug.cgi?id=646855
The fade effect when switching tabs should only be applied when
switching from a previously selected tab, not when selecting the
initial one - otherwise, the window previews are faded in the first
time the overview is shown.
https://bugzilla.gnome.org/show_bug.cgi?id=644389
