Refresh rates are an important information for users, even if they
can't change them.
This is especially true for cases where knowledge of the refresh
rate may influence the decission about the resolution to use.
Consider the example where a display may support `3840x2160@60Hz`
and `2560x1440@144Hz`. When choosing `3840x2160` as resolution,
the refresh rate will likely get hidden, making the user unaware
of the fact that they will maybe not get what they want (potentially
144Hz).
So follow the example of e.g. the sound panel where input and output
devices are listed in dropdowns, even if they are the only options
selectable.
Note: while this is a design change, for a big group of users this
won't actually change the default experience as Mutter until recently
had a bug to duplicate 60Hz modes in many cases. So most laptop users
already saw the refresh rate panel in previous Gnome versions,
dispite it having little use.
See also:
fb9564b87b
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.
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
This means we show the first 5 scales that are supported for the
display. That is the same behaviour as 3.30 had, therefore minimizing
the UI changes that users will see.
Note that there are plans to improve the scaling UI, however, it is not
yet clear how this will look like.
