We assume that the RR configuration is valid in various callbacks from
both our modal dialogs which doesn't hold if there's an hotplug while
a dialog is open (e.g. monitor is plugged/unplugged).
Closing the dialog in that case seems the right thing to do since it
would be operating on an outdated view of the world otherwise and
likely end up crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=655041
GnomeRRMode is a boxed type which means that if stored as such in a
tree model, the model creates a copy to use internally. In addition,
it means that gtk_tree_model_get() will also get a copy which must be
freed by the caller which we were not doing.
In this case though, we don't need the copies since all the
GnomeRRModes that we use outlive the model so we can simplify things
by just storing a plain pointer in the model instead.
https://bugzilla.gnome.org/show_bug.cgi?id=655041
Otherwise we could fail to validate the new configuration depending on
which output we're initializing mirror mode from.
gnome_rr_config_applicable() creates a temporary array of outputs for
validation and, in clone mode, all of them are assigned the same
geometry but, since it lacks context about which output the user is
currently on, it just uses the first one's geometry for all of
them. If this first output isn't the one the user is changing in the
UI then we never called _set_geometry() on it with a clone mode
geometry and thus the validation would fail because the geometry used
is that output's current mode which might not match the clone mode's.
https://bugzilla.gnome.org/show_bug.cgi?id=743816
CcRRLabeler assumes an X11 session using override redirect toplevel
windows which are positioned in global desktop coordinates. Since this
isn't available on Wayland sessions, we're moving to a DBus API which
gnome-shell implements and works the same on both X11 an Wayland
sessions.
As side-effects, we get native looking gnome-shell OSD labels without
having to mimic the style ourselves and we're also now able to easily
show labels on mirrored setups.
https://bugzilla.gnome.org/show_bug.cgi?id=743743
When rotating a screen, the user has to first select the kind of
rotation and then press Apply. However, the meaning of the symbolic
icons may not be clear before actually pressing one of them.
This patch adds appropriate tooltips to the buttons so that the user has
a textual clue about what is going to happen.
https://bugzilla.gnome.org/show_bug.cgi?id=743888
This achieves a very similar result (darkening the background color)
without having to peek into the style context. Note that the stroke
is removed because it isn't really visible anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=740986
This is deprecated in newer automake versions, and this causes warnings
with automake 1.14:
panels/printers/Makefile.am:3: warning: 'INCLUDES' is the old name for
AM_CPPFLAGS' (or '*_CPPFLAGS')
https://bugzilla.gnome.org/show_bug.cgi?id=732189
When rotating the left-most monitor, we could end up with one
of two scenarios:
- Huge gap between monitor one and two when the left monitor is made
to be vertical
- Monitor two overlapping on top of monitor one when monitor is
back to being horizontal.
In addition to adding a bit more debug, we now take the old and new
rotation of monitor one into account when calculating the moving
screen edges.
https://bugzilla.gnome.org/show_bug.cgi?id=731166
Consider whether rotation has changed when checking whether
we need to relayout the screens. Before, we would only have changed the
layout if the resolution changed.
This doesn't fix the problem of the relayouting code not taking rotation
into account, but it will at least allow us to run that code when only
the rotation changes.
https://bugzilla.gnome.org/show_bug.cgi?id=731166
It's a likely word that might be used when looking for this panel and,
with the new search results ordering, the power panel is coming up
ahead due to it preferring keyword matches when they exist.
https://bugzilla.gnome.org/show_bug.cgi?id=729027
We create rotate_box only when show_rotation is TRUE, and the
conditions for checking the different kinds of rotation do not make
sense when show_rotation is FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=727023
If running under wayland, we can't use an X property notify
to look at workarea changes.
Currently, workarea is not part of the wayland protocol, so don't
bother and just don't crash.
https://bugzilla.gnome.org/show_bug.cgi?id=705573
The way we apply the new configuration changed, in that we are
expected to call the apply() method of GnomeRRConfig ourselves,
and that takes care to call to mutter, show the confirmation
dialog, etc.
https://bugzilla.gnome.org/show_bug.cgi?id=705573
The coordinates of the cairo_t in GtkWidget::draw() is always
based on the origin of the widget, i.e. the allocation, even
for drawing on subwindows or whatnot. So, we can delete
all the user_to_device() code.
This also fixed input when the new Gtk+ drawing model changes,
as that will change the device coordinates reported (but not the
user coordinates).
Very few of the panel comments provide information that is very
useful. Update them to supplement the panel descriptions - this
will make the search results more helpful.
https://bugzilla.gnome.org/show_bug.cgi?id=694110
