In almost all cases, the configuration will be "valid" in the sense that
g-c-c can represent it in the UI. However, there are cases like
mirroring setups with three monitors that we do not allow.
In case that the user has such a configuration, ensure that the
configuration we represent is actually valid according to our
expectations. This should not affect normal use cases, but allows users
to recover again if the configuration is broken for some reason.
Fixes#383
When the user has more than two monitors, then they can disable each
monitor separately. If the user creates an invalid configuration because
they disabled the last monitor, then enable a different one immediately.
The new logic selects a single configuration type rather than detecting
which types can be considered valid. This simplifies the UI rebuilding
somewhat, but also changes some internal behaviour. We will now always
be in the correct mode internally, even if the UI may not represent this
change (i.e. with more than two monitors it always looks the same).
We should show unusable monitors in the monitor selection drop-down
list. So always add them to the combobox and add the code to make the
switch to enable them insensitive.
We should only enforce single mode, when we have exactly two monitors
and the two button UI is used to switch between them in single mode.
Move the code to ensure the single configuration into the relevant
callback handler, rather than trying to solve this globally.
We need to also set rebuilding while updating some other UI elements.
Make it into a counter to allow for recursive setting.
Note that additional checks for rebuilding will be added in later
commits.
It generally makes more sense to reset the resolution of a monitor after
we switch configuration types. The main case where this is relevant is
switching from a mirror configuration (CLONE) to either join or single.
In this case, higher resolutions for monitors may become available.
Note that this might be annoying to some users, because there may be
monitors reporting a lower "preferred" resolution than the highest
supported resolution. There is little we can do though, as always
selecting the highest resolution doesn't seem like a much better
approach.
If no monitors are enabled, then the variant would end up with an
invalid variant type, causing a crash later on. This case only happened
due to other bugs (i.e. in principle we should never send a
configuration without any monitors to the server).
Prevent the serialization error by specifying the correct type for the
builder, therefore potentially preventing a crash in such a corner case.
When enabling the first monitor, we need to select it as primary as we
otherwise end up without a primary monitor (rendering the configuration
invalid). "Unsetting" the NULL primary monitor effectively causes the
first and only available monitor to become the primary, while not doing
anything if we have a primary monitor.
The new code had a bug in that it only ever enabled the first monitor
rather than all usable ones. Fix this by removing the erroronuous break.
Also clarify the comment a bit that the current solution is not really
ideal as it may result in invalid configurations (i.e. we enable more
outputs than are possible with the number of available CRTCs).
Fixes#418
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.
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
For now, this patch only adds the context to the Resolution option to
disambiguate it from the display panel. This makes the code more complex
though, and will be changed again to add the context to all options
(making the strings identical to the ones in GTK+).
Fixes#394 for the printing panel
Put the widget's content into a HdyColumn, itself into a
GtkScrolledWindow. This allows the panel to reach narrower sizes.
This deliberately doesn't adapt the indentation of the contained widget
to help this commit to be more readable and easier to review, it will be
adapted in the next commit.
There's only one instance of this pattern - make the function specific
to that case rather than generic.
The current code is leaking the Label2Data struct and the GSettings
signal connection. The leak of the signal connection was causing a crash
in case the callback was called after the label was destroyed. Instead
of just directly fixing these problems, let's eliminate the intermediate
struct and just support the specific case we're interested in directly.
The current code relies on GLib API and uses the
available mounts to calculate the available partition
size. This is because this code assumes that more
than one OS can be installed in the same drive, and
wouldn't make sense to show the whole disk size in
this situation.
That, however, clashes with the general purpose of
the panel, for it is meant to show general information
about the user's computer, and it is not reporting
the full disk size.
Fix that by using the UDisks API to get the real size
of the full disks.
https://bugzilla.gnome.org/show_bug.cgi?id=639376
Slighly modified by Iain Lane <iainl@gnome.org> to
port to meson and add udisks2 to CI deps.
Fixes#285.
Fixes#302.
In the User Accounts panel's carousel, longer real names
push the window geometry to super wide levels -- even with
the 255-char limitation in place.
Fix that by ellipsizing the real name label.
GNOME Settings allows limitless full names, which is
actually accepted by most of the stack but may break
GNOME Settings, GNOME Shell and other user-visible
applications that show the user names.
Limit the user full name entries to 255 characters,
which is the same value used by GNOME Initial Setup.
