Rest in peace you magnificent format, love-child of arcane X11 drawing
API and markup craze, you will not be missed.
We do remember however the bravery of a many men and women, who fearlessly
descended into the guts of your intrinsics and turned ugliness into beauty;
their work will still be spoken of when you will long have been forgotten.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
Going through GSD's settings was done in context of patches that
did not land; it is simpler and more consistent with GTK+ to use
the corresponding XSetting instead.
We shouldn't scale the cursor size in mutter we g-s-d exports
the correct size on hidpi so use gtk-cursor-theme-size.
This way we also catch changes on resolution updates.
https://bugzilla.gnome.org/show_bug.cgi?id=729337
This reverts commit 4fe66ce0a9.
This is wrong ... we should not scale the cursor size but read
the cursor xsettings that gets exported by gsd. Also this won't update on
resolution changes.
https://bugzilla.gnome.org/show_bug.cgi?id=729337
We commonly used the generic, undetailed signal 'changed' to track
changes to preferences. Since we crash on unknown preference types,
this can be dangerous if somebody adds a new setting that has a
type we're unfamiliar with, and something else changes it.
Instead of crashing, just fizzle out doing nothing.
Now that the internal mutter bindings and gnome-shell stopped using
META_KEY_BINDING_REVERSES, and after moving the 'adding shift reverses
the keybinding action' logic to gnome-control-center, we can remove
META_KEY_BINDING_REVERSES from mutter.
Plugin API is broken as this constant is removed from the exported
headers. ABI is broken as using this flag is now a noop.
https://bugzilla.gnome.org/show_bug.cgi?id=732385
We want to synchronize the button layouts of our server side
decorations and GTK+'s client side ones. However each currently
may contain buttons not supported by the other, which makes this
unnecessarily tricky.
So add support for a new "appmenu" button in the layout, to display
the fallback app menu in the decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=730752
Warnings that are going to the journal should be not translated:
they're not user visible, and translating them would just make
bug reporting harder (as now the developers need to understand
what the warning is saying)
https://bugzilla.gnome.org/show_bug.cgi?id=707897
Switching meta/util.h to gi18n.h was wrong, mutter is a library
and needs gi18n-lib.h, but that cannot be included from a public
header (since it depends on config.h or command line options),
so split util.h into a public and a private part.
https://bugzilla.gnome.org/show_bug.cgi?id=707897
If a binding is updated with a clear set of strokes (effectively
disabling it) we aren't signaling that the binding changed and thus
the previous strokes will continue to be grabbed.
This fixes that and tries to do a better effort at checking if the
binding changed or not.
https://bugzilla.gnome.org/show_bug.cgi?id=697000
As we only had one string-array preference so far, we didn't bother
with adding a generic way to handle string-array preferences, and
just handled the preference in question explicitly. However we are
going to parse another string-array setting, so generalize the
existing code to make it reusable for that case.
https://bugzilla.gnome.org/show_bug.cgi?id=700223
Window menus use the first key combination for a binding to show the
acceleration, so the list must be in the right configured order, which
is the opposite of what's built by g_slist_prepend()
https://bugzilla.gnome.org/show_bug.cgi?id=694045
MetaButtonLayout is extremely unfriendly for introspection: its fields
are arrays of a fixed length, but the actual length is determined by
a custom stop value (e.g. not NULL / 0).
Without API changes this will never work nicely in introspection, but
we can at least make it work; start by filling up unused fields with
the stop value rather than leaving it at random values.
https://bugzilla.gnome.org/show_bug.cgi?id=689263
As the overlay key works differently from normal keybindings, it
requires special treatment. However, by adding a rudimentary
MetaKeyBinding for it, we will be able to confine the special
handling to mutter and treat it like any other keybinding in
the shell.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
Moving focus immediately on crossing events as we currently do
in focus-follows-mouse mode may trigger a lot of unwanted focus
changes when moving over unrelated windows on the way to a target.
Those accidental focus changes prevent features like GNOME Shell's
application menu from working properly and are visually expensive
since we now use a very distinct style for unfocused windows.
Instead, delay the actual focus change until the pointer has stopped
moving.
https://bugzilla.gnome.org/show_bug.cgi?id=678169
When changing the overlay-key setting, the change only takes effect
on restart - there are actually two bugs involved:
(1) the test whether the key has changed is located in the
else part of a test for string settings (and overlay-key happens
to be a string settings ...)
(2) with (1) fixed, a change signal is emitted, which triggers a
reload of all keybindings - unfortunately, the actual value
of overlay-key is only read on startup, so the key is reloaded
using the old value
Fix both issues by replacing the custom handling of the overlay-key
with the regular handling of string preferences.
https://bugzilla.gnome.org/show_bug.cgi?id=681906
