Use our native JS error system in the "extension system" API, only
using the signal/log-based error reporting at the last mile. Additionally,
delete the directory if loading the extension failed, and report the error
back over DBus.
https://bugzilla.gnome.org/show_bug.cgi?id=679099
Instead of using the 'extension-state-changed' signal to relay errors,
use DBus's native error mechanism to inform the method caller that the
call has failed. This requires making the method actually asynchronous
so that we don't block the browser, which is stuck waiting for a reply
from the browser plugin. To ensure this, we need to modify the browser
plugin API to ensure its extesion installation method is asynchronous.
Additionally, this lets us remove the awful, broken hacks that we used
when a user clicked the "Cancel" button, replacing it by a DBus return
value.
https://bugzilla.gnome.org/show_bug.cgi?id=679099
When the extension downloader was originally designed, the information
downloading part was inserted at the last minute, along with the modal
dialog as a security feature to make sure an extension didn't silently
get installed on the user's machines either due to a security issue in
the browser-plugin, or an XSS issue on the extensions website. Correct
the mistake I made when writing the code; instead of dropping an error
on the floor, log it correctly. This "bug" has already bitten a number
of users who forgot to configure proxy settings in the control center.
https://bugzilla.gnome.org/show_bug.cgi?id=679099
Pam seems to give us different strings, sometimes 'Password:',
sometimes 'Password: '. Look for both of these when replacing
them with a translated prompt.
https://bugzilla.gnome.org/show_bug.cgi?id=675300
The current position below "System Settings" is problematic - the
items are unrelated, and misclicks will result in a scary system
modal dialog that has to be cancelled.
Move items around a bit to avoid this problem.
https://bugzilla.gnome.org/show_bug.cgi?id=678887
Right now the "move to workspace" keyboard shortcut transition isn't smooth. It
shows the window disappearing, hopping to the next workspace, and then sliding
into view. "Pin" the window to the stage while the animation is in progress,
then release it afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=660839
Install a custom handler for move-to-workspace-* keybindings that
shows the workspace switcher, which gives the user a sense of
direction when navigating with the keyboard.
https://bugzilla.gnome.org/show_bug.cgi?id=674104
Most of code implementing workspace switches was repeated with
minor differences on each direction. Instead, consolidate it
and use the new meta_workspace_get_neighbor.
https://bugzilla.gnome.org/show_bug.cgi?id=674104
When using dbus-glib, single return values were special-cased to
be returned verbatim rather than as array with a single element.
This is no longer true since switching to GDBus, so fix the places
where the change was overlooked.
https://bugzilla.gnome.org/show_bug.cgi?id=678852
We strongly expect applications to use the same values for the
'Title'/'Icon' fields in their search provider .ini file as the
'Name'/'Icon' fields in their .desktop file. Rather than requiring
applications to duplicate those fields, allow them to specify a
'DesktopId' field instead to point to the corresponding .desktop
file, which makes it possible to ship search provider files without
translatable strings (which is nice given that merging translations
into search provider files lacks a standard rule).
https://bugzilla.gnome.org/show_bug.cgi?id=678816
Currently we pass an icon name for the 'icon' parameter of the
RemoteSearchProvider constructor. In hindsight, using a GIcon
instead will give us a bit more flexibility, so change it.
https://bugzilla.gnome.org/show_bug.cgi?id=678816
Use the ShellMountOperation dialogs we have to implement a DBus API
allowing other processes to display them.
Since GtkMountOperation now tries to call into our DBus implementation,
every application that uses a GtkMountOperation will gain integration
with our shell dialogs (but will still handle the actual communication
with GVfs).
https://bugzilla.gnome.org/show_bug.cgi?id=678516
Wait until the completion of the mount operation before dismissing the
passphrase dialog, so in case it fails, we can re-use the same dialog
with an error message (like e.g. PolicyKit auth dialogs) instead of
showing a brand new one.
https://bugzilla.gnome.org/show_bug.cgi?id=674962
Wifi and mobile broadband have signal indicators and are thus
more useful than vpn icons in the panel. Therefore, in the case
we have both wifi/3g and VPN we prefer the former as the "primary
icon" and add a lock next to it.
Behavior when VPN is added to wired or other connections is still
preserved: the wired icon is replaced by vpn.
https://bugzilla.gnome.org/show_bug.cgi?id=672591
Sorting by strength is what the other OSes do by default, and it
provides a better UX (by offering your hotspot and router before
the one from your neighbor).
https://bugzilla.gnome.org/show_bug.cgi?id=658946
Only apply the allowAutorun flag for transient notifications, not for
mounts that end up in the resident notification well.
Also, stop looking at volume.can_automount() here, since we already
checked that previously in the mounter, and allowAutorun is enough.
https://bugzilla.gnome.org/show_bug.cgi?id=660595
Previously, a volume was being ignored from autorun if one of these two
conditions were met:
- its mount root file had a native scheme and was mounted in a
non-hidden location
- it had a volume that could have been automounted, and had a flag set
by the shell to allow autorun
In order to effectively ignore volumes that we don't mount ourselves
from our notification system, we have to meet both conditions at the
same time instead.
https://bugzilla.gnome.org/show_bug.cgi?id=660595
This is a fallout from some changes in MessageTray.Source, which now
requires either defining the iconName/iconType properties on it, or
implementing createNotificationIcon, and we're not doing any of those.
Fix it by storing the gicon of the source object and using a helper
method to create the icon actor on demand, to avoid any case when the
same actor might be added twice to different containers.
https://bugzilla.gnome.org/show_bug.cgi?id=678428
The dependency chain spirals out from folks->zeitgeist->xapian...and
I'm really not interested in pulling in all of that into the core
shell.
There is work on splitting out contact search into gnome-contacts; I'd
add a bug link but Bugzilla is down.
When the shell takes control of the screen (for example to show
a modal dialog or to lock the screen), it must reestablish itself
on top of the stack, and in particular restore any unredirected
window so that it is composited below the Shell UI.
Reviewed-By: drago01 in IRC.
There is a race if a channel is invalidated during its preparation: the
'invalidated' signal is already emitted so the Shell will never notice.
We fix this by simply checking if the channel is already invalidated when
receiving it from telepathy-glib.
In the approving case, we reject the full ChannelDispatchOperation as we only
support approving one channel at the time.
https://bugzilla.gnome.org/show_bug.cgi?id=677457
Initially, extensions were loaded after they shell had fully created
the session and all objects, but this didn't allow extensions easy
ways to monkey patch prototypes, as most functions had already been
bound. Remove the historical vestigal function, and just merge the
two together.
https://bugzilla.gnome.org/show_bug.cgi?id=677586
A large amount of extensions have something like this in them:
function init() {}
Since we have encouraged extension authors to try and not make any
changes in init, it feels weird and strange to have to create an
initialization function that does nothing. From now on, don't require
it.
https://bugzilla.gnome.org/show_bug.cgi?id=677586
This allows us to move to a file-monitor based approach in the future.
Since we need signals, we convert the current set of functions to an
object we attach signals too, leading to the new ExtensionFinder object.
https://bugzilla.gnome.org/show_bug.cgi?id=677586
