This adds a new listbox with a single row, as per
mockups, to switch to the Night Light page; and
also adds a back button to switch back to the main
page.
Fortunately for us, AdwPreferencesGroup makes that trivial.
Move the linked box into an AdwActionRow, and remove the icon
and the margins from the toggle buttons.
Ignored in Meson < 0.60.0, deprecated since 0.60.1 and fatal since 0.61.0.
panels/applications/meson.build:10:5: ERROR: Function does not take positional arguments.
panels/background/meson.build:10:5: ERROR: Function does not take positional arguments.
panels/camera/meson.build:10:5: ERROR: Function does not take positional arguments.
[...]
Mutter sends modes in descending order of preference. By reverting
the order via `g_list_prepend`, we get unintended side effects
such as choosing the least preferred refresh rate by default (if
the selected mode is not marked as preferred).
Instead of adding complex logic in several places, make sure that
the assumption of descending preference is kept by simply not
inverting the order.
Closes https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1562
On small window sizes the ButtonBox can overflow the panel. This is
especially true in single display mode when no other elemnts prevent
shrinking to e.g. 360px width on phones. Use the ComboBox introduced in
632cb3c907 in these cases.
For that we introduce cc_display_settings_refresh_layout() to refresh
the layout when the folded state changes. This can later on be used for
more tweaks to shrink to smaller sizes.
Rebuilding the UI would trigger the scale to be re-applied. This in turn
would cause the monitor to be snapped and possibly changing a correct
configuration.
Note that this really is a bug in the snapping code. But that code is a
mess and not fireing the signal is a good thing either way.
Closes: #1412
In case fractional scaling is enabled, depending on the resolution,
mutter may advertise many fractional scaling values which are way more
than MAX_SCALE_BUTTONS, making impossible to use higher fractional
scaling values in high dpi setups.
So, in case scaling is possible, show them as buttons if they fit the
buttons limit, otherwise fallback to a combo box that is consistent with
the rest of the UI and will allow to use any valid scaling value.
In the front-end we define a minimum size and then we check every time
we iterate through resolutions or scales if such mode is valid.
Since the configuration won't change, we can just filter the invalid
values once when the minimum allowed size is set, so that we can be sure
that the returned scales list is always matching the ones appliable for
the current mode.
The only edge case is when using a cloned configuration, as in this case
the values need to be applied to all the monitors.
However, since we already return a reffed GArray we can just create a
temporary one in this case where unappliable scales are skipped.
As per this we can just use around the scales array length as the number
of visible buttons.
It's just a nicer api and allows us to avoid having to count all the
elements around or to expose the size via an out value.
Given this is a private API anyway there's no risk for modifying the
array, so it's something safe to use anyways.
This makes scaling work e.g. on the Librem 5's built-in display which
has a 720x1440 resolution. It's scaled to 200% by default so currently
hitting the 100% button makes it scale to 100% but then the 200% button
vanishes due to assumed too small resultion. Fix that by allowing for
360x720 as well.
When swicthing configurations, we should ensure that the selected scale
is valid. This is complicated by the fact that it depends on other
factors whether we need a single global scale or not.
Try to retain the scale that monitors have if possible. If that does not
work, try to use the old scale of the primary monitor everywhere. This
should result in a good behaviour in most situations.
Co-authored-by: Stéphane Travostino <steph@combo.cc>
Fixes: #1038
The UI rebuilding code may change the configuration type, which in turn
can trigger a UI rebuild. This should not be done if we are already
updating the UI (but must be done otherwise, as that means the user has
chosen to change the configuration).
Fixes: #1141
Gnome-control-center checks the display modes by
cc_display_config_is_scaled_mode_valid()
...
cc_display_config_dbus_is_scaled_mode_valid()
to exclude unusable low resolutions.
However, it is the current using resolution that going to be tested by
is_scaled_mode_allowed() in is_scale_allowed_by_active_monitors(), if it
is global scaled required or configured as cloning mode originally.
Therefor, it will check current using resolution again and again,
instead of the enumerated one. This leads gnome-control-center building
wrong resolution list on the panel.
This patch replaces the current mode with the enumerated mode to have
the correct resolution to be tested by is_scaled_mode_allowed().
Fixes#903
Make the panel class provide a cancellable that will be cancelled when the panel
is destroyed. Panel implementations can use this and not have to mangage the
cancellable themselves. Consolidate cases where panels had multiple cancellables
that were all being used for this behaviour.
Monitors may not always have a mode. This means we cannot look up the
mode on the fly, but instead need to have a heuristic to select a mode
if there is none.
Everything was in place already for this, except that one location was
still doing a fresh lookup, possibly causing a crash.
Fixes: #675
"Primary Display" and "Contains top bar and Activities" are visible when
you have >1 display connected and the "Join Displays" option is
selected. I can't work out how to see the "Active Display" string but it
sure looks translatable to me.
