This reverts commit ec8ed1dbb0.
1) It turns out to add a momentary flicker from the transition
between the login screen and user session
2) It actually isn't needed anymore since bug 733026
https://bugzilla.gnome.org/show_bug.cgi?id=740377
The set/unset branches of meta_display_update_pointer_emulating_sequence()
have been split and put directly where it makes sense. The pointer emulated
sequence will be updated before processing the CLUTTER_TOUCH_BEGIN, and
after processing the CLUTTER_TOUCH_END, this way the checks on this hold
true during all the sequence lifetime.
https://bugzilla.gnome.org/show_bug.cgi?id=738411
Returning FALSE here gets the button release event propagated to the
client on wayland, which is unexpected after xdg_surface.move/resize()
have been called.
https://bugzilla.gnome.org/show_bug.cgi?id=738888
Commit 2f9c601 accidentally changed the logic here, changing the grab
behavior when not using raise-on-click. Fix this.
Spotted-by: Adam Goode <adam@spicenitz.org>
Fullscreen windows look weird when they are overlapped by system chrome,
which currently happens when another window is stacked above. We used to
auto-minimize fullscreen windows in that case, which proved to be both
unreliable and unpopular. So instead, keep the system chrome hidden even
when the fullscreen window is not stacked at the top.
https://bugzilla.gnome.org/show_bug.cgi?id=693991
The constructor would collect windows that are sticky before initializing its state
which would lead to a crash in the case of windows with struts which trigger a work
area recalculation where mutter would assume, due to uninitialized state, that an
existing work area has to be freed.
https://bugzilla.gnome.org/show_bug.cgi?id=738384
There's a small window before a window that is being unmanaged is
unregistered with the display. The MetaScreen::window-left-monitor
and MetaWorkspace::window-removed emissions fall right into that
window, so code that runs in that time may well be out of our
control; we can make sure that the method it can use to get an
updated list of windows no longer contains the destroyed window
though, which is a much better option than expecting everyone to
filter the list themselves.
In Wayland, popup window types are not override-redirect, and thus can
steal window focus away from their parent window when clicked on.
This means that we need to make sure their appearance is properly
propagated to the parent windows so the parent windows don't lose their
focus while they're propagated.
Since we now directly expose the reverses bindings directly, we
don't have to have this special-case in do_choose_window.
More importantly, if the backwards binding is pressed and has the Shift
key included, this will actually revert it
This doesn't matter for Alt-Tab in gnome-shell, which already replaces
it with a better Alt-Tab replacement, but it does matter for Alt-Esc,
which switches between windows directly.
Windows are relocated before their workspace is removed, however this
is only necessary for windows that are *only* on that workspace; for
windows on all workspaces, that step is annoying as it will unset the
sticky state requested by the user.
https://bugzilla.gnome.org/show_bug.cgi?id=737625
The workspace MRU lists are updated when windows are managed/unmanaged
or change workspaces. However those updates obviously only apply to
existing workspaces - new workspaces will always start out with an empty
MRU list, despite sticky windows already being "on" that workspace.
As we now assert that the list contains all windows located on the
workspace, we need to initialize it correctly to avoid a crash.
https://bugzilla.gnome.org/show_bug.cgi?id=737581
We only grant requests to set the demands-attention hint if the window
is at least partially obscured; so for non-minimized windows on the
active workspace, we check if any other window on the same workspace
that is higher in the stack overlaps.
However in the case of a sticky window, window->workspace is NULL, so
we end up considering any non-sticky window on a different workspace.
At this point we have already established that the window is showing
on the active workspace, so use that to filter for windows that may
overlap.
Since the introduction of set_workspace_state(), window->workspace
will always be NULL when on_all_workspaces is set - passing that
to a workspace function that does not validate its input will then
result in a crash.
Use the get_workspace() function instead, which will always return
a valid workspace.
Since commit 2eec11b445, windows without a __NET_WM_DESKTOP property
that should be on all workspaces are not added to the active workspace;
this is correct, however not adding them to any workspace is not ...
set_workspace_state () returns early when the desired sticky state
and workspace match the current property values, assuming that the
corresponding MRU lists are already correct in that case.
However that might not be the case when we are setting the initial
state, so don't take the shortcut in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=737178
A window may either be sticky because it has been requested as such,
or because it is placed on a non-primary monitor (and the corresponding
preference is set). While we do take the latter into account, we
currently override the sticky state later during initialization;
be a bit more careful there to get the initial state right.
https://bugzilla.gnome.org/show_bug.cgi?id=737178
Commit 1af0033368 made a subtle change
regarding how XKeysymToKeycode behaves. It does a depth first search
while XKeysymToKeycode is documented to do a breadth first search:
"this function looks in each column of the core keyboard mapping in
turn and returns the lowest numbered key that matches in the lowest
numbered group" - from the XKB library documentation
Looping over all keycodes for each layout and level index makes us go
back to the previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=737134
With the change to how hidden windows are stacked, the position
of the guard window with respect to the hidden windows got flipped
and the guard window was at the bottom of everything; fix it to
be on top of the hidden windows.
https://bugzilla.gnome.org/show_bug.cgi?id=737233
Commit 2f229c3928 removed the code to compute the above-tab
keycode and replaced it with a simple constant from linux/input.h.
We obviously cannot depend on linux headers on non-linux systems,
so provide a fallback definition in that case (which is expected
to work assuming the system is using the Xorg xf86-input-keyboard
driver).
https://bugzilla.gnome.org/show_bug.cgi?id=737135
The titlebar rect is in window coordinates, while screen regions are
obviously not. Fix by translating into screen coordinates before
testing for overlaps.
https://bugzilla.gnome.org/show_bug.cgi?id=736915
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.
Restacking the frame for a window while unmanaging the window is
harmless, but for undecorated (in particular, client-side-decorated)
windows, this causes problems because the window is typically
destroyed by the client immediately after withredrawing the window.
Skip windows flagged as being unmanaged when assembling the new
stack and when comparing the old order to the new stack.
Add a stacking test for this.
