gtk_stack_set_visible_child_name() doesn't actually make a child
visible if the child widget isn't visible already which means we'd
always start in the first ("join") stack page even if the currently
applied configuration is one of the others.
https://bugzilla.gnome.org/show_bug.cgi?id=786767
As mutter now has removed the legacy monitor config system and the
associated property on org.gnome.Mutter.DisplayConfig, also remove the
support from gnome-control-center.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This implements most of the new Display panel re-design by Allan
Day.
Left out for now is brightness setting which still is in the
Power panel because the plumbing layers don't yet associate backlights
with outputs.
Also left out is the presentation mode and trimming of options due to
hardware constraints since we don't have a mutter implementation for
those yet.
https://bugzilla.gnome.org/show_bug.cgi?id=785949
Whether a mode is interlaced or not is now exported by adding a
'is-interlaced' (b) value to the mode properties variant. Implement the
is_interlaced() vfunc using this information.
The mode format communicated via the new D-Bus API changed to
specifying modes using a per monitor unique mode ID string. The uint
'flags' was also changed to more flexible a{sv} 'properties' structure.
Mutter's new display configuration API allows configurable per-monitor
scales within a finite set determined by mutter. We expose the
available values in a simple slider widget for each monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
The new API checks with mutter every time update_apply_button() is
called and mutter is very strict about this so it already does these
adjustments internally.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
When setting the primary monitor off we were setting all other
monitors as non-primary which is clearly wrong. It only worked
correctly because the backend code in GnomeRR would implicitly
select a primary for us.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
Use mutter's new display configuration API if it's available or
fallback to the old API via GnomeRR. The new API requires a new way to
identify outputs so we also need to use an alternative monitor labeler
API.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
This adapts as much as possible mutter's new display config API to the
current display panel's expectations. In particular we keep the
concept of logical monitors hidden from the panel. They will later be
exposed when we re-design the panel to make full use of the new API.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
This removes the direct dependency on GnomeRR while keeping the
existing functionality.
All the tiled monitor special casing was removed since the new API
doesn't expose tiled monitors in the first place.
A check for virtual size limits was removed but it wasn't being
enforced anyway.
We also introduce a blank error state for when the backend API isn't
available.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
This will allow us to switch the display panel away from using the
GnomeRR api directly in order to gracefully move to a new DBus display
configuration API to be provided by mutter while still keeping the
existing functionality on top of the GnomeRR api while the new one
is developed.
https://bugzilla.gnome.org/show_bug.cgi?id=782785
We hard-code a 16x16 asset for sunrise and sunset icons, which makes
them look blurry at higher scaling factors.
Let's look in the icon theme to see if there's an icon for sunrise and
sunset; if not, we can still use the assets we ship, but we also attempt
to load them from different resource paths, depending on the scale
factor.
We will need to update the assets to include a 32x32 rendering of the
sunrise and sunset icons.
https://bugzilla.gnome.org/show_bug.cgi?id=781029
We need to check the interlaced flag too when preselecting the current
resolution in the combo box since we now have separate entries for
interlaced and regular resolutions of the same size.
https://bugzilla.gnome.org/show_bug.cgi?id=772708
If no items are added to the GVariantBuilder, g_variant_builder_close()
would throw a critical, g_variant_builder_end() would throw a
segmentation fault.
As this can only happen when there are no items added to the output_ids
hashtable, this should only happen if there are no displays known to
libgnome-desktop (and therefore mutter).
See https://bugzilla.redhat.com/show_bug.cgi?id=1280075https://bugzilla.gnome.org/show_bug.cgi?id=771875
