The active_connection might be null, but the NMApplet code might
still belive the device wrapper is the primary connection (because
dbus signals are emitted one after the other).
(Also, remove an old and wrong comment about bluetooth in wwan code)
Fixes:
(gnome-shell:22511): Gjs-WARNING **: JS ERROR: Exception in callback for signal: icon-changed: TypeError: this._device.active_connection is null
NMDeviceWired<.getIndicatorIcon@resource:///org/gnome/shell/ui/status/network.js:475
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NMApplet<._updateIcon@resource:///org/gnome/shell/ui/status/network.js:1790
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
_emit@resource:///org/gnome/gjs/modules/signals.js:124
NMConnectionSection<._addConnection/<@resource:///org/gnome/shell/ui/status/network.js:265
_emit@resource:///org/gnome/gjs/modules/signals.js:124
NMConnectionItem<._sync@resource:///org/gnome/shell/ui/status/network.js:137
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NMConnectionItem<.setActiveConnection@resource:///org/gnome/shell/ui/status/network.js:169
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
NMConnectionDevice<._activeConnectionChanged@resource:///org/gnome/shell/ui/status/network.js:327
wrapper@resource:///org/gnome/gjs/modules/lang.js:169
https://bugzilla.gnome.org/show_bug.cgi?id=723570
This reverts commit 5d05b66902.
Had a long discussion with Bastien Nocera and Allan Day on IRC about
this and in the end we decided to go with the simple on/off controls for
now.
Conflicts:
js/ui/status/location.js
https://bugzilla.gnome.org/show_bug.cgi?id=723684
Add more time to the fade in/out animation when switching
views so they don't switch abruptly and add a delay
between view switch animations to avoid morphing.
https://bugzilla.gnome.org/show_bug.cgi?id=722331
Split the current implementation of SourceActor into
SourceActor and SourceActorWithLabel.
In this manner we can use source actors withouth count labels,
required in the screenShield to not clash with the count
text label.
https://bugzilla.gnome.org/show_bug.cgi?id=709275
When exact accuracy (i-e GPS) is available, allow user to disable that.
When users don't want application to get their precise location, they
can now opt for network-based geolocation only, which can be
street-level at best.
https://bugzilla.gnome.org/show_bug.cgi?id=723684
Instead of relying on geoclue to store this user configuration, lets
keep it in gsettings. Geoclue is a system service and therefore is not
the appropriate entity to keep this info.
https://bugzilla.gnome.org/show_bug.cgi?id=723684
Instead of overriding the actor's request with the icon size, just set
the new icon size on the actors, and let the default handler take the
preferred size of children.
https://bugzilla.gnome.org/show_bug.cgi?id=705410
Now that we are indicating 'geolocation in use' to user, we better also
provide at least a way to disable geolocation. Once this is in place, we
can provide slightly better controls rather than simply on/off switch.
https://bugzilla.gnome.org/show_bug.cgi?id=723684
The current middle-click action of opening a new window on a new
workspace is a bit peculiar; it is also not overly hard to achieve
the same result by moving a new window to the desired workspace or
selecting a workspace before opening a new window. Just opening
a new window is also a more common action, so having a shortcut
available that doesn't require a modifier is a good idea as well;
change the middle-click behavior accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=695010
Having terminal launchers behave differently than any other launchers
is non-obvious and confusing. Remove the special-casing to restore
consistency, we will make the new window action more accessible
instead.
This reverts commit 68faba6bde, 4ed0f3e5f0
and 887a21afb9.
https://bugzilla.gnome.org/show_bug.cgi?id=695010
The design says that the noise texture is the implicit bottom
layer, and so it's appropriate to use it togheter with the default
color to cover the dead area outside the screen which becomes
visibile when scrolling.
https://bugzilla.gnome.org/show_bug.cgi?id=724305
In addition to checking the current settings, check also if the
zoom region is active before registering the event listener.
This way, we avoid DBus traffic for events we're not interested in.
Also, make FocusCaretTracker resilient to multiple register/deregister
calls (which can now happen).
https://bugzilla.gnome.org/show_bug.cgi?id=724305
It's possible that the DBus call goes in timeout (which is bad,
but unavoidable, given that atspi is synchronous) or fails
because the component has been removed (race condition). Those
errors are not dependent on gnome-shell, but on faulty applications
(mostly).
If they happen, log a debug message and continue.
https://bugzilla.gnome.org/show_bug.cgi?id=724305
The log handler can be invoked at bad times, and in particular
it can be invoked from gsignal with the signal lock taken.
At that time, calling into arbitrary high-level APIs can
cause a dead-lock.
Instead, only send to telepathy the tp-glib debug messages.
Everything else is in the journal anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=724256
