Windows that start up in a size that is almost as big as the workarea create
extra work for the user (resizing or maximizing) so save the user's time by
detecting such windows and automaximize them.
https://bugzilla.gnome.org/show_bug.cgi?id=671677
Basically we don't really want to create windows that are almost maximized in
size but not actually maximized. This creates work for the user and makes it
very difficult to use and resize manually.
So set the newly unmaximized window size to the previously used size or 80% of the
size of the current workarea (attempting to retain natural aspect ratio if
possible), whichever is smaller.
https://bugzilla.gnome.org/show_bug.cgi?id=671677
Some modifiers like NumLock and ScrollLock don't make sense in
keybindings, which is why we ignore them when matching keybindings
to events. We should do the same in Javascript, so add an accessor
function.
https://bugzilla.gnome.org/show_bug.cgi?id=665215
The move-to-corner keybindings weren't treated as user actions, which
resulted in them not affecting the saved position - they weren't
always being treated as sticky. Marking them as a user action revealed
bugs in the positioning logic that were hidden by the constraint
code applied to automated moves. Fix those as well. Bug tracked
down by Mariusz Libera.
https://bugzilla.gnome.org/show_bug.cgi?id=661256
We currently sync the number of workspaces with the corresponding
preference. This is not really useful with GNOME Shell's dynamic
handling of workspaces, not least as the setting is effectively
ignored. Worse, it will trigger writes to dconf on login, slowing
down startup, so add a setting to indicate that workspaces are managed
dynamically and really ignore the num-workspaces setting when set.
https://bugzilla.gnome.org/show_bug.cgi?id=671568
We were relying on GTK+ emitting GtkWidget::style-updated during
widget initialization to create the GtkStyleContexts used for
window decorations. A recent GTK+ update broke this assumption,
so do the necessary initialization ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=671796
Mutter originally started out with the idea that only a subset of the total
API was exposed to plugins, so some APIs are duplicated on MutterPlugin.
We've long since abandoned that idea; remove these wrappers.
https://bugzilla.gnome.org/show_bug.cgi?id=671103
After _unmanage the object is semantically dead even if technically it's not,
so remove the prefs listener here to prevent it being called for a dead
object.
In particular this fixes a crash when starting up gnome-shell with at least
one gimp utility window opened which causes mutter to create a MetaWindow for
it only to immediately get an UnmapNotify afterwards which causes mutter to
unmanage the MetaWindow. Afterwards prefs_changed_callback is called for this
dead MetaWindow and tries to dereference the window->monitor pointer which is
already NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=671087
The experimental Cogl api cogl_texture_pixmap_new() was recently changed
so it now expects an explicit CoglContext argument and it can also
return exceptions now via a GError. This patch updates mutters use of
the api accordingly.
