st_theme_node_get_border_image() may return %NULL, leading to a
segfault in st_border_image_get_file() when glib is compiled with
G_DISABLE_CHECKS.
https://bugzilla.gnome.org/show_bug.cgi?id=780381
Our weather integration should follow GNOME Weather as closely as
possible, which means that we should respect its location permission
rather than using our own or none at all (which we can as a "system"
component and as geoclue's authorization agent).
https://bugzilla.gnome.org/show_bug.cgi?id=780252
It doesn't make sense to tie the proxy code for flatpak's permission
store to the location indicator, just because that was the first
component to use it, so split it into a separate module.
https://bugzilla.gnome.org/show_bug.cgi?id=780252
The setting to globally disable location settings altogether isn't
handled by the geoclue service itself, but by the authorization
agent. This means that:
- it doesn't apply to system components
(which gnome-shell is now considered[0])
- it doesn't apply once the geoclue connection
has been authorized
However users can reasonably expect that we won't use location services
after they disabled them, so handle the setting explicitly.
[0] https://cgit.freedesktop.org/geoclue/commit/?id=a4cef6c0ad08https://bugzilla.gnome.org/show_bug.cgi?id=780252
We currently use automatic location for weather forecasts if the
corresponding Weather setting is set, however we should take other
factors into account as well:
- whether location services are enabled at all
- whether Weather has been authorized to use them
In preparation of these changes, track the setting's value in a
separate property and make _useAutoLocation a getter, so we can
extend it with additional conditions easily.
https://bugzilla.gnome.org/show_bug.cgi?id=780252
Setting GWeatherInfo:location to null helpfully doesn't mean
"no location", but "NYC". This obviously isn't what we want
to show users, so track the location validity separately and
consider it when updating the label shown to users.
https://bugzilla.gnome.org/show_bug.cgi?id=780252
When using the 'disable-lock-screen' setting to lock down the screen
lock, the expectation is that users cannot lock the screen. However
as it turns out, all the setting currently does is hiding the lock
button in the system menu and making the lock settings in the privacy
panel inactive. That means that if the 'lock-screen-enabled' setting
isn't disabled and locked down as well, we will just continue to
lock the screen on inactivity - not to mention the keyboard shortcut
that isn't subject to that setting anyway.
Instead of expecting administrators to hunt down every possible way
of locking the screen and disabling it individually, we can easily
handle all cases by refusing to lock the screen when disabled by the
lockdown settings.
https://bugzilla.gnome.org/show_bug.cgi?id=780212
Dragging and dropping app icons is expected to work anywhere over a
workspace, however overlaid elements are added to a separate hierarchy
and can thus block valid drop targets. This wasn't much of an issue
while we had just the window title, but since the addition of the
focus border, drops on window previews stopped working entirely.
Fix this by hiding all non-reactive overlay elements from picks.
https://bugzilla.gnome.org/show_bug.cgi?id=737166
We rely on the service to detect whether a fingerprint reader is
present. It is fine to not support fingerprint authentication
when the service is missing, but currently we don't handle this
case at all and end up with a non-functional login screen.
https://bugzilla.gnome.org/show_bug.cgi?id=780063
Currently when the wifi selection dialog is open when the screen lock is
activated, the dialog remains visible above the shield. This is clearly
broken, so close the dialog automatically on session mode changes if the
mode doesn't allow settings (as changing the access point is arguably a
user setting).
https://bugzilla.gnome.org/show_bug.cgi?id=780054
