The step where we requery the stacking order from the server than combine
it in an arbitrary fashion with Wayland windows can be eliminated by observing
that we are the final authority for Wayland window stacking - so if we
apply each X event that we receive from the X server to our stack in a
way that leaves the X windows ordered in the same way as on the server,
and apply events that we have stored locally in a way that doesn't affect
the ordering of X windows, than we have a fully correct ordering of windows.
Ordering this in the order of first applying the X event and then applying the
local portion also means that as long as we had an up-to-date view of the X
stack the composite operation will be identical to what was requested.
https://bugzilla.gnome.org/show_bug.cgi?id=736559
Putting X windows and pointers to MetaWindows into a union had a number of
problems:
- It caused awkward initialization and conditionalization
- There was no way to refer to Wayland windows (represented by
MetaWindow *) in the past, which is necessary for the MetaStackTracker
algorithms
- We never even cleaned up old MetaStackWindow so there could be
records in MetaStackWindow pointing to freed MetaWindow.
Replace MetaStackWindow with a 64-bit "stack ID" which is:
- The XID for X Windows
- a "window stamp" for Wayland windows - window stamps are assigned
for all MetaWindow and are unique across the life of the process.
https://bugzilla.gnome.org/show_bug.cgi?id=736559
Add a private hook for the test framework to get XSyncAlarmEvent events -
this will be used to implement XSyncCounter based synchronization
so that the test framework can deterministically wait until Mutter
has seen actions performed by an X11 client.
https://bugzilla.gnome.org/show_bug.cgi?id=736505
Setting the scaling factor immediately after calling clutter_init()
avoids creating the stage at one size, then later resizing it to
a different size.
https://bugzilla.gnome.org/show_bug.cgi?id=736279
We can enter weird states where get_default_window is called during
window unmanagement, before the window has been fully removed from
the stack. Make sure these windows are *never* returned from
get_default_window, as focusing them can cause an assertion fail,
or worse.
Clutter events include the layout index codified into modifier_state,
unlike XI2 device events, which means that we need to mask it out so
that we can match successfully.
A lot of applications assume that the window is fully positioned when it
gets the MapNotify, especially simple applications. Make sure that the
window is only mapped through the calc_showing logic.
O-R windows appear in workspace->windows, which aren't relocatable,
so we can't simply check if the workspace is empty after relocating
all normal windows, since those windows remain.
Make sure that the only windows we have are those that are
on_all_workspaces.
This is bad behavior, and can also cause us to get in an infinite loop
if an OR window is mapped and unmapped in quick succession. This
sequence causes a MapNotify followed by an UnmapNotify, and when
processing the events, we'll call XMapWindow, XUnmapWindow, which will
put another set of MapNotify, UnmapNotify events in our queue, which we
then process by calling XMapWindow, XUnmapWindow, and so it goes
forever, or at least some scheduler uncorks us by making us call
XMapWindow when the window is already mapped, or XUnmapWindow when the
window is already unmapped.
We can stop this madness by simply making sure never to call neither
XMapWindow or XUnmapWindow on OR windows, which is the correct thing to
do anyway.
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.
In gnome-shell, we have a feature where the user can unmaximize windows
by dragging them from the panel above the window. With accurate
anchoring, this looks really weird as the cursor is now "detached" from
the window. Detect this case and put the cursor in the middle of the
window titlebar instead.
This seems to be more accurate with what we currently see in
GNOME. Without having the app expose this information to us, it might be
a better idea to use the default frame style for this information instead.
The cursor was anchored wrongly when trying to unmaximize windows from
dragging them from the top of the screen because of a few think-o's and
some code that forgot to be updated when we moved to the frame rect
coordinate system.
The cursor is still offset for windows that start dragging from the top
panel. This is technically correct, but looks wrong. We'll fix this in
the next commit.
The initialization sequence before was quite icky, initializing Clutter
in a few different places depending on what was going on.
Put that all back into main.c
This removes our Xwayland dependency in the native path. The direct
grabs are still there for the X11 backend and are a bit disgusting,
but that's OK. We can refactor it out later.
This introduces some pretty lousy hackery because it depends on
https://github.com/xkbcommon/libxkbcommon/pull/10 , and I really
don't want to wait on that to squash this dep.
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
Currently the bindings for {switch,cycle}.* actions are created with the
META_KEY_BINDING_REVERSES flag so that <shift>+binding triggers the
reverse action. However, gnome-control-center does not know about this
kind of implicit bindings, and, for example, cannot warn when the user
tries to setup a conflicting <shift>+xxx binding.
These backward <shift> bindings are being explicitly set in
gsettings-desktop-schemas, so the META_KEY_BINDING_REVERSES annotation
can be removed for them from mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=732385
MetaKeyBinding can be marked as being reversed
(META_KEY_BINDING_IS_REVERSED), but MetaKeyHandlerFunc callbacks
cannot check whether this flag was set or not on the MetaKeyBinding
which triggered the callback.
https://bugzilla.gnome.org/show_bug.cgi?id=732295
The existing workspace management code is quite hairy, with plenty of
logic inline in all of window.c, workspace.c, and screen.c, making it
hard to understand or make changes to, since you might forget to change
several of the other places the code was around.
Rewrite the internal workspace management logic so that it's
centralized and all in window.c. Document the invariants we need to
maintain, and ensure that these invariants are properly kept, with
asserts in various places.
Extensive testing on gnome-shell did not bring up any issues, and this
is a considerable cleanup.
This will be used to replace some of the hooks that are used to call
into window.c, so that the workspace index property is properly kept up
to date.
We can't name the property "index" since it causes conflicts with the
meta_workspace_index method. This should really be called
meta_workspace_get_index, but oh well.
I accidentally broke this in commit a119ea9. The code was considerably
more complicated than it needs to be, so let's replace it with a
g_list_find and nothing more.
Scanning over the hash table of XIDs is a terrible idea. Not only were
we excluding Wayland windows, but we were also looking at alarms and
barriers, too. We were lucky that that only contained GObjects where
our checks would work.
