If the GCancellable is cancelled by the finalize() function, the
callback will still be called potentially with an instance of the
panel that's not valid anymore.
To avoid crashing in that case, only access the priv pointer
when we have no error.
https://bugzilla.gnome.org/show_bug.cgi?id=761846
It doesn't make sense to try to validate pages because widgets are
changing due to the whole dialog being destroyed and it causes a bunch
of warnings because some resources are cleared on each page dispose
method.
Avoid all that by disconnecting the page "changed" signal handler
before we start destroying widgets.
We don't need secrets for new connections and, in fact, trying to
retrieve secrets in that case will fail because we have a plain
NMConnection instead of a NMRemoteConnection.
The above mentioned error would result in the page never being
initialized.
The way we destroy the window during the handling of a clutter event may
cause the window to generate a focus event that gets processed immediately,
causing Clutter to deadlock on its global lock.
Bypass these issues in the places where we finalize out of Clutter events,
The Esc key presses are now handled at the GTK+ level, and we postpone
finalization (with either success or failure) to an idle.
Works around https://bugzilla.gnome.org/show_bug.cgi?id=747880
We don't yet support wacom devices under wayland and GsdWacomDevice
uses X APIs unconditionally which makes us crash under wayland.
Instead, let's return early and leave the GsdWacomDevice in an invalid
state which means that we just present the default UI for "no wacom
devices detected".
The formats (or 'region') setting might be unset meaning that it's the
same as the language since that's what LC_TIME et al default to when
unset.
We already handle this for the user setting but for the system setting
we're losing that semantic when getting it from localed since we don't
allow priv->system_region to remain unset. This means that when users
change the system language, the system formats will be explicitly set
to the previous value of the system language instead of remaining
unset and thus follow the new value for the system language.
This isn't that bad on multi user systems where we display system
settings separately from user settings, but on single user systems we
change the system values to match the user values which, due to the
above mentioned semantic difference regarding the region setting,
means that when changing the language, the (unset) region will be
displayed as the same as the language but the system region will be
explicitly set to the previous language.
Fix this by making the system region have the same semantic as the
user's, i.e. allow it to remain unset until explicitly set by the
user.
https://bugzilla.gnome.org/show_bug.cgi?id=755648
