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
Make it possible for panels to go all the way to the edge of the
shell. This is particularly important for panels that scroll, such
as the new power panel. All other panels are changed to compensate
for the loss of external padding.
https://bugzilla.gnome.org/show_bug.cgi?id=691229
