GitLab

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.

These cases were safe, but if the code changed this risked freeing uninitialized
memory.

Benjamin Berg authored Aug 12, 2019 and Benjamin Berg committed Aug 27, 2019

Some devices have panels with a native resolution in portrait mode. In
these cases the monitor will likely be used in landscape mode.

Accept the modes as if they are landscape rather than portrait. A
further improvement would be to restrict the orientation setting.

Fixes #639

Benjamin Berg authored Jul 03, 2019 and Georges Basile Stavracas Neto committed Jul 20, 2019

This may happen under some conditions. Possibly due to a race condition
(i.e. we did not receive any configuration from mutter yet) or also if
we are not running on GNOME.

Add guards for NULL configuration. This configuration is never
applicable and mostly clears the UI.

Fixes: #604

Benjamin Berg authored Apr 11, 2019 and Benjamin Berg committed Jul 15, 2019

The function has been changed in gnome-shell to be called ShowMonitorLabels
again (rather than ShowMonitorLabels2). Update g-c-c accordingly.

See GNOME/gnome-shell!491

This introduces a GtkStack to handle the pages; move the
current panel to be the "displays" page; and adds the
Night Light page as "night-light".

A stack switcher was added, as a header widget, to control
the stack.

GNOME/gnome-control-center#533

And create the dialog manually instead. The next commit
will move it to a different page in the panel itself,
so not much care was put into makin the dialog perfectly
matching.

GNOME/gnome-control-center#533

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.

Benjamin Berg authored Mar 18, 2019 and Georges Basile Stavracas Neto committed Mar 18, 2019

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 GNOME/gnome-control-center#419

Benjamin Berg authored Mar 07, 2019 and Georges Basile Stavracas Neto committed Mar 11, 2019

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.

Benjamin Berg authored Mar 07, 2019 and Georges Basile Stavracas Neto committed Mar 11, 2019

While the configuration was updated, the apply button was not synced.
This meant users could not switch the active monitor properly.

Fixes #405

Benjamin Berg authored Mar 07, 2019 and Georges Basile Stavracas Neto committed Mar 11, 2019

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.

It will be used from multiple files in the future.

We were converting the floating point numbers to integers using a cast,
which causes them to be always rounded down. The result is that a
monitor may be too small by a pixel, creating broken configurations.

Also fix the same issue when calculating whether a scale should be
supported.

See GNOME/mutter#412

Anything that affects the size of the screen (or its existance) may
result in invalid configurations. Do a small effort in trying to fix
this by calling into the snapping algorithm for the modified monitor.

Addresses issue #247 to a large extend.

Daniel Drake authored Oct 08, 2018 and Georges Basile Stavracas Neto committed Oct 17, 2018

Previously, low resolutions were hidden from the control center
because when such display modes are activated, GNOME is unusable;
many important UI elements do not fit on the screen at all.
https://bugzilla.gnome.org/show_bug.cgi?id=626822

This was removed in c0f686bb
without explanation; reinstate it here.

Also prevent the scaling from being selected or activated if the
effective scaled resolution would result in an equivalently low
resolution being used.

Benjamin Berg authored Oct 16, 2018 and Georges Basile Stavracas Neto committed Oct 17, 2018

We need to re-sync the scale button scale when updating the state
dynamically. Otherwise changing the resolution will always show a scale
of 100% (first item) rather than the actual active one.

Benjamin Berg authored Oct 16, 2018 and Georges Basile Stavracas Neto committed Oct 17, 2018

The visibility is explicitly controlled in the functions that create the
rows in question. This regression was introduced in commit 3d177b67
(display: Don't use gtk_widget_show_all).

Robert Ancell authored Oct 12, 2018 and Georges Basile Stavracas Neto committed Oct 11, 2018

It is removed in GTK+ 4

As the main headerbar used by the shell is split, the title is not
propagated to the window. However, the "apply" header bar is not split
and the title is propagated to the toplevel GtkWindow.

Fix this issue by resetting the window title again.

Fixes GNOME/gnome-control-center#81

This commit improves the Night Light code in various
ways:

 * Turn it into a template class, subclass of GtkDialog,
   and adapts all the code to reflect that.

 * Update the code style in various places, to make it
   more conformant with the documented code style.

 * Reorganize the code a bit, moving functions around,
   to make it more conformant with the documented order.

Benjamin Berg authored Dec 22, 2017 and Georges Basile Stavracas Neto committed May 28, 2018

This adds the following API:
 * cc_display_config_get_ui_sorted_monitors
   Returns the monitors in UI order
 * cc_display_config_count_useful_monitors
   Counts the useful monitors (active and usable)
 * cc_display_monitor_is_useful
   Checks if a monitor is active and usable
 * cc_display_monitor_is_useable
   Check if a monitor is marked as useable
 * cc_display_monitor_set_usable
   Used to mark builtin monitors as unusable if the lid is closed
 * cc_display_monitor_get_ui_*
   Get the UI number and strings for display

https://bugzilla.gnome.org/show_bug.cgi?id=786971

Benjamin Berg authored Dec 08, 2017 and Georges Basile Stavracas Neto committed May 28, 2018

The comment was not updated when the workaround in the code was removed.

https://bugzilla.gnome.org/show_bug.cgi?id=786971

Benjamin Berg authored Nov 24, 2017 and Georges Basile Stavracas Neto committed May 28, 2018

Remove the code that has become unused with the new arrangement widget.

There are more possible cleanups as there is some code duplication
between cc-display-panel.c and cc-display-arrangment.c at this point.

https://bugzilla.gnome.org/show_bug.cgi?id=786971

Benjamin Berg authored Nov 24, 2017 and Georges Basile Stavracas Neto committed May 28, 2018

This commits adds a new arrangement widget, refactoring the existing
code and addressing a number of issues:
 * Forced snapping made laying out more than 2 monitors hard
 * Random gaps would be shown between monitors
 * The scaling was fixed and usually tiny

https://bugzilla.gnome.org/show_bug.cgi?id=786971