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
Following the previous patch, this patch adds the new alternative
categories to the panels' Desktop files. These alternative categories
are only relevant for the alternative Shell, and do not break the
current Shell in any way.
https://bugzilla.gnome.org/show_bug.cgi?id=767301
Commit b3be076 added soft hyphens along with a comment for translators
to use those soft hyphens. Except that gettext would only grab the one
line out of the four we wrote for translators to read. Put them all on
the same line so that gettext actually extracts those.
https://bugzilla.gnome.org/show_bug.cgi?id=765778
Note that this fix will not automatically fix translations, which will
need to add soft-hyphens (U+00AD) to their translations themselves, and
will not fix larger fonts for which the split up syllables end up
being bigger than the maximum text width.
It's the best we can do without redesigning the Settings shell, which is
already something planned.
https://bugzilla.gnome.org/show_bug.cgi?id=647087#c13
Adds a switch that allows to control overscan compensation, when the
driver supports it.
Based on a patch by Tomeu Vizoso <tomeu.vizoso@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=725135
When a mode has 2 very close refresh rates such as 59.94Hz and 60Hz,
most of the time, we'll want the 59.94Hz version.
Hide the "PC" 60Hz version and only show the 59.94Hz version in those
cases, and mark the frequency as "60Hz (ATSC)" so that those
knowledgeable know that it's really 59.94Hz, and doesn't confuse those
who expect rates to be multiple of 30Hz or 25Hz.
See also https://en.wikipedia.org/wiki/NTSC#Lines_and_refresh_rate
Note that we also do this for half and double that rate, eg. close to
~30Hz and ~120Hz.
https://bugzilla.gnome.org/show_bug.cgi?id=655041
There's really no point showing a resolution that's smaller than the
fixed width of the shell, and isn't the preferred resolution for the
screen either. This stops the problematic 720x576 resolution showing on
an HD screen.
Don't break out of loop if we weren't primary, as this
is stopping the user swapping back and forward between
primary and secondary with a tiled monitor.
i.e. user sets monitor to secondary and attempts to
go back to primary and it fails to move it.
https://bugzilla.gnome.org/show_bug.cgi?id=751680
This moves the two functions to the top of the file, changes the
get_geometry to return x/y if requested, and refactors the callers to
use it.
It also refactors some code that open coded the same basic code.
https://bugzilla.gnome.org/show_bug.cgi?id=750312
If there's an accelerometer builtin to the display, don't show the
rotation buttons, it will be handled by the user rotating the display,
eventually with the rotation lock in use.
https://bugzilla.gnome.org/show_bug.cgi?id=750410
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
