When a mode has 2 very close refresh rates such as 59.94Hz and 60Hz,
most of the time, we'll want the 59.94Hz version.
Hide the "PC" 60Hz version and only show the 59.94Hz version in those
cases, and mark the frequency as "60Hz (ATSC)" so that those
knowledgeable know that it's really 59.94Hz, and doesn't confuse those
who expect rates to be multiple of 30Hz or 25Hz.
See also https://en.wikipedia.org/wiki/NTSC#Lines_and_refresh_rate
Note that we also do this for half and double that rate, eg. close to
~30Hz and ~120Hz.
https://bugzilla.gnome.org/show_bug.cgi?id=655041
We should be pairing gtk_window_get_size with
gtk_window_set_default_size to avoid inconsistencies between the size
reading and setting code. eg., in recent GTK+ versions,
gtk_window_get_size and gtk_widget_set_size_request differ in their
interpretation of the CSD chrome.
However, gtk_window_set_default_size didn't work with non-resizable
GtkWindows, until now.
https://bugzilla.gnome.org/show_bug.cgi?id=762548
We should be pairing gtk_window_get_size with
gtk_window_set_default_size to avoid inconsistencies between the size
reading and setting code. eg., in recent GTK+ versions,
gtk_window_get_size and gtk_widget_set_size_request differ in their
interpretation of the CSD chrome.
However, gtk_window_set_default_size didn't work with non-resizable
GtkWindows, until now.
https://bugzilla.gnome.org/show_bug.cgi?id=762548
We should be pairing gtk_window_get_size with
gtk_window_set_default_size to avoid inconsistencies between the size
reading and setting code. eg., in recent GTK+ versions,
gtk_window_get_size and gtk_widget_set_size_request differ in their
interpretation of the CSD chrome.
However, gtk_window_set_default_size didn't work with non-resizable
GtkWindows, until now.
https://bugzilla.gnome.org/show_bug.cgi?id=762548
Latest gnome-shell (3.19.91) now asks user if they'd want to allow the
application to gain access to their location information when an
application tries to access this information. The user's choice is saved
in xdg-app's permission store and user can no longer can change their
mind about this later on. Hence the need to provide these per-application
controls in control-center.
https://bugzilla.gnome.org/show_bug.cgi?id=761245
There's very few chances that the universal-access will fit in the
minimum height of the shell for panels, so just nuke that.
This also fixes the panel taking 1px in height until we switch away from
it and back to it.
https://bugzilla.gnome.org/show_bug.cgi?id=761939
There's really no point showing a resolution that's smaller than the
fixed width of the shell, and isn't the preferred resolution for the
screen either. This stops the problematic 720x576 resolution showing on
an HD screen.
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
