When comparing configurations, the monitor positions are compared
directly. This comparison will not work properly if one of the
configurations has an offset.
This results in the "Apply" button to show up incorrectly after moving
the top/left monitor position.
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 https://gitlab.gnome.org/GNOME/mutter/issues/412
This adds a scale to change the color temperature from 3000K to
6000K. A mark is added to the default value and a second one for
aesthetics.
Initial implementation by Benjamin Berg
Color choices by Daniel Foré and elementary OS
Closes#147
Presumably, they are nonwritable because a system administrator has locked
these settings down.
https://help.gnome.org/admin/system-admin-guide/stable/dconf-lockdown.html
If Night Light is locked on, don't show the Off button.
If Night Light is locked off, don't show the Manual or "Sunset to Sunrise" buttons.
If Manual is force-enabled, don't show "Sunset to Sunrise" or the other way around.
When changing the display mode, the apply button does not appear if the
current mode and new mode differ only in their interlaced flag.
The display mode comparison function now takes the interlaced flag into
account.
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.
This is a function working only on a configuration which runs the
snapping with infinite snapping. This allows forcing a monitor that has
been modified to be adjacent to at least one monitor.
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 c0f686bb0f
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.
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.
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).
The night light dialog is both marked as "destroy_with_parent" and explicitly
destroyed in the panel. Drop one of these.
Causes the warning after opening the dialog then closing the app:
(gnome-control-center:19887): Gtk-CRITICAL **: 11:00:01.370: gtk_widget_destroy: assertion 'GTK_IS_WIDGET (widget)' failed
This bug was introduced in ed36688c58
There was an issue where the "minor" axis snapping would not be done if
the "major" axis snapping had a zero distance. This could be seen when e.g.
moving a monitor on the right up/down slightly. In that case, no
snapping to align the bottom/top edges were done unless you also moved
the mouse sideways a bit.
Fixes#211
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 https://gitlab.gnome.org/GNOME/gnome-control-center/issues/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.
This improves the snapping behaviour in a number of ways. It allows
increasing the snapping distance while still helping the user to align
monitors by snapping a different distance for the minor axis. The patch
also allows setting this distance to infinity so that we get the correct
behaviour in the case of two monitors for the corners.
Two monitors are a special case where it is easy to ensure that the
monitors are always adjacent to each other by special casing the
snapping code. Do so by increasing the snapping distance to infinity and
adding extra snapping points so that corner cases are covered.
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
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
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
dialog_got_proxy_cb and dialog_got_proxy_props_cb may be called after the
instance of CcNightLightDialog has been disposed. Make sure 'self' pointer is
not dereferenced if not valid.
Fixes: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/86
When the user creates temporary invalid configurations the dialog used
to hide the apply button as if no change had been done so far. Change
this to show the normal "Apply"/"Cancel" titlebar but make the "Apply"
button insensitive and modify the title to indicate the error.
Unfortunately we don't currently get the reason in a way that we could
translate it. Ideally we would special case common error scenarios and
present the user with a better explanation or even correct the mistake.
See https://bugzilla.gnome.org/show_bug.cgi?id=790891 for the related
mutter bug.
https://bugzilla.gnome.org/show_bug.cgi?id=790792
