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
StWidget considers "same theme node" as an indication that the style
did not change, and skips emitting style-changed in that case. This
means that icon theme changes are not picked up by StIcon.
https://bugzilla.gnome.org/show_bug.cgi?id=689353
this._gnomecc is currently unused; we actually need a GAppInfo for this
provider if we want to display an icon next to it (see future commits),
so just turn it into one.
We might move this to an external provider altogether in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=689735
This allows us to fix the shortcomings of the original ActivateResult()
method. In particular:
- allow to pass the search terms to the provider
- allow to pass a user interaction timestamp
https://bugzilla.gnome.org/show_bug.cgi?id=689735
The only case when we're interested in using those parameters nowadays
is for DnD, which is handled in a separate method already.
Since we're not going to support DnD for non-app search results anyway,
drop the params from all the activateResults() calls; this will be
useful later since we're going to add another parameter to it.
https://bugzilla.gnome.org/show_bug.cgi?id=689735
We read the implemented version from the search provider's keyfile, and
then create a RemoteSearchProvider object from the right class
accordingly.
Wire ActivateResult() to the new method (without actually passing the
new parameters along) - an actual implementation will be added in a
future commit.
https://bugzilla.gnome.org/show_bug.cgi?id=689735
We are going to change the interface, so add a new version of it.
Providers will need to opt-in to the new API.
A summary of the differences compared to the previous API:
- ActivateResult() now also takes the search terms and a timestamp as
parameters
- a new LaunchSearch() method is added
https://bugzilla.gnome.org/show_bug.cgi?id=689735
Defining a mode that differs significantly from the default one
can get rather cumbersome. For convenience, allow mode definitions
to inherit from an existing mode.
https://bugzilla.gnome.org/show_bug.cgi?id=689308
As currently envisioned, the fallback replacement in 3.8 should be
a separate session at the login screen. As we will use extensions
to implement this mode, we need a way to specify extensions per
session rather than per user, so add a session-mode property for
extensions that should be loaded in addition to the user-defined
ones.
https://bugzilla.gnome.org/show_bug.cgi?id=689305
Currently adding a new session mode requires patching the sources.
As defining custom modes can be desirable in some circumstances
(for instance for administrators of kiosk setups), load additional
modes from JSON files.
https://bugzilla.gnome.org/show_bug.cgi?id=689304
Now that we use the new 'switch-applications' keybinding for the
application-based alt-tab popup, we can use the 'switch-windows'
keybinding for a more traditional switcher.
Based heavily on the alternate-tab extension from Giovanni Campagna.
https://bugzilla.gnome.org/show_bug.cgi?id=688913
The Shell's alt-tab popup is application-based, so using the
'switch-windows' keybinding for it never really made sense.
Use the newly added 'switch-applications' keybinding instead.
https://bugzilla.gnome.org/show_bug.cgi?id=688913
Decorations are fairly uncommon in gnome-shell, so it's
worthwhile to avoid effort creating empty attr lists. This
can also help prevent a relayout.
https://bugzilla.gnome.org/show_bug.cgi?id=689400
