Currently pressing the overlay key only triggers the overview if
no other key is pressed between KeyPress and KeyRelease. Extend
this logic to pointer events, so that KeyPress + ButtonPress actions
are treated explicitly different from "pure" overlay key presses.
In particular, this change allows to re-use the overlay key as mouse
button modifier.
https://bugzilla.gnome.org/show_bug.cgi?id=662476
If we want to support keybindings from extensions installed in the user's
directory, we can't take a schema, as the GSettings object needs to have
a special GSettingsSchemaSource.
https://bugzilla.gnome.org/show_bug.cgi?id=673014
Starting the auto-maximize process on a window like a
META_WINDOW_DESKTOP window that is not maximizable gets placement into
a confused state and eventually results in the window being positioned
at the wrong position (the position that an auto-maximized window would
be restored to.)
https://bugzilla.gnome.org/show_bug.cgi?id=673566
When mutter recognizes a full-screen window, it tries to raise it to the top
of the stack. Unfortunately, a recent rewrite of the stack code didn't do
well with raising a window to the top of the stack if the stack wasn't in
a consistent state -- it would crash. Ensure that the stack is in a consistent
state at the top of meta_stack_raise/meta_stack_lower.
https://bugzilla.redhat.com/show_bug.cgi?id=806437https://bugzilla.gnome.org/show_bug.cgi?id=672797
Commit 2fc880db switched from focusing the topmost window as the default
window to focusing the MRU window. This was done in alignment with the
introduction of per-workspace MRU lists to avoid problems where the window
stack was inadvertently changed when focusing windows during window switches.
Now that focusing windows don't have as big an impact on the stacking order,
we can revert back to focusing the top window, which is less confusing to the
user.
For now, leave per-workspace MRU lists, as they're a pretty good approximation
of a global MRU list, and it works well enough.
https://bugzilla.gnome.org/show_bug.cgi?id=620744
This is a new value, not associated with any keybindings, useful
when the WM needs to order the applications by last-interaction,
taking into account all windows.
https://bugzilla.gnome.org/show_bug.cgi?id=667552
"warning: 'match_tile_mode' may be used uninitialized in this function", it
complains. It thinks it's not unused because of other values of
window->tile_mode, but other complex logic ensures that it can't be
META_TILE_MAXIMIZED, so this is a safe commit.
Windows that have minimum widths larger than the screen can't be maximized,
even though we put them in a maximized state and allow users to do so:
the window just won't change size and position. Fix this by simply not giving
the option to maximize, like what happens for non-resizable windows.
https://bugzilla.gnome.org/show_bug.cgi?id=643606
A lot of code did something similar to:
MetaFrameBorders borders;
if (window->frame)
meta_frame_calc_borders (window->frame, &borders);
else
meta_frame_borders_clear (&borders);
Sometimes, the else part was omitted and we were unknowingly using
uninitalized values for OR windows. Clean this up by just testing
for a NULL frame in meta_frame_calc_borders and clearing for the
caller if so.
https://bugzilla.gnome.org/show_bug.cgi?id=643606
Since we're going to be evaluating the work area at startup now, we need
to make sure that we don't iterate over workspaces before they're assigned.
The easiest way to do this is to make sure that meta_window_get_workspaces
doesn't crash.
https://bugzilla.gnome.org/show_bug.cgi?id=643606
