As per the binding that we have between the list store and the combo-box, when
the first element is added to the list-store, the combo box set this value as
the selected-index, and this leads to a call to cc_display_monitor_set_primary
which set the first-listed monitor as primary and unset the real primary monitor.
To avoid this, just ignore the binding when rebuilding the UI, since in this
phase control-center should just reflect the actual state without changing
anything.
Fixes https://gitlab.gnome.org/GNOME/gnome-control-center/issues/419
GNOME/gnome-control-center!387 ported info panel to use UDisks2 instead
of GUnixMounts and thus the helpers from gsd-disk-space-helper.[h|c] are
no more needed.
Disabled monitors may or may not have a mode selected. This means, we
need to skip the mode comparison if the two compared monitors are
disabled (i.e. have no logical monitor).
Move the mode check to the end and skip it if both monitors are disabled.
This fixes cases where identical configurations are misdetected, because
we applied a mode to a monitor and disabled the monitor again. This
happens for example when switching the active monitor in "single" mode.
In the case where the user plugged/unplugged a screen, we could run into
the case where we would first enable and then disable the same output.
This could potentially result in an invalid configuration.
Prevent this by not disabling the output if no switch happened.
The dialog tried to retain the current configuration mode. However,
doing so means that we end up in the wrong mode in some situation (e.g.
opening the dialog with two displays but only one enabled).
Fix this by always selecting a configuration mode. This potentially
switches the user from "join" to "single" if only one monitor is left.
However, the user has no way to do this manually, so no unexpected UI
change will happen.
Currently they are built from cron, but we can use Gitlab's
only:
changes:
- path
support to also trigger on path changes. This is restricted to only work
for pushes for master, so that branches / merge requests don't attempt
to rebuild the image.
accountsservice has 1 MB limit for avatars, however, users panels
refuses to show avatars bigger than 64 KB for some historical reasons.
But you can still successfully set avatars up to the accountsservice
limit. Let's remove this custom limit and other redundant check and
rely just on accountsservice limits and errors from GDK.
https://bugzilla.gnome.org/show_bug.cgi?id=792243
Default set of avatars uses 512x512 currently. However, custom avatars
from file, or webcam are always scaled down to 96x96. Let's increase this
also to 512x512. This change should be safe, because theoretical maximal
file size is 1 MB, which is equal to accountsservice limit.
https://bugzilla.gnome.org/show_bug.cgi?id=792243
