The main monitor of a window is maintained as 'window->monitor' and is
updated when the window is resized or moved. Lets avoid calculating it
every time it`s needed.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
The existing private get_monitor_neighbor() function returns a
MetaMonitorInfo, which is private as well. Add a public wrapper
that returns a monitor index instead, as we do for other public
monitor-related methods.
https://bugzilla.gnome.org/show_bug.cgi?id=633994
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
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
Since MetaStackTracker is the code that knows about the current X stacking order
and the relationship between X windows and Wayland windows, it's cleaner to
encapsulate stack manipulation in MetaStackTracker rather than have the calling
code make the X calls and only call into MetaStackTracker to inform it about
the changes.
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
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.
This allows creating the stage much earlier than it otherwise would have
been. Our initialization sequence has always been a bit haphazard, with
first the MetaBackend created, then the MetaDisplay, and inside of that,
the MetaScreen and MetaCompositor.
Refactor this out so that the MetaBackend creates the Clutter
stage. Besides the clarity of early initialization, we now have much
easier access to the stage, allowing us to use it for things such as
key focus and beyond.
The current GNOME Shell Alt-F2 restart looks very messy and also
provides no indication to the user what is going on. We need to
restart the compositor to switch in and out of stereo mode, so
add a framework for doing this more cleanly:
Additions:
meta_restart(): restarts the compositor with a message
MetaDisplay::show-restart-message: signal the embedding
shell to show a message
MetaDisplay::restart: signal the embedding shell to restart
itself.
meta_is_restart(): indicates whether the current instance is a
restart so we can suppress login animations.
A helper program meta-restart-helper holds the composite overlay
window up during the restart to avoid visual artifacts.
https://bugzilla.gnome.org/show_bug.cgi?id=733026
There's no obvious reason for grabbing the X server when unmanaging
a screen - the only race conditions a server grab solves are those
related to querying and then acting on the results of the query.
Our shutdown sequence is correctly ordered according to the ICCCM -
we first unselect on the root window, and then we destroy the
window owning WM_S<n> so removing the grab should not cause any
problems when we are being replaced with another window manager.
https://bugzilla.gnome.org/show_bug.cgi?id=733068
Commit 8100cefd4c fixed a crash during workspace initialization by
tweaking the startup sequence; as a result, the plugin (like gnome-shell)
is now started before workspaces are fully initialized, which breaks
some reasonable assumptions (like always having an active workspace).
This is particularly problematic considering that the code making those
assumptions is not necessarily our own (extensions!), so return to
fully initialize workspaces before the compositor again.
At the same time, make sure to only call meta_workspace_activate()
once during initialization to avoid reintroducing the crash.
https://bugzilla.gnome.org/show_bug.cgi?id=732695
Since commit 8b2b65246a, we assume that the compositor always
exists. Alas, the assumption is wrong - the compositor is currently
initialized after the screen, but meta_screen_new() itself may
call a compositor function if initialization involves a workspace
switch (which will happen when meta_workspace_activate() is called
more than once and for different workspaces - or in other words,
when _NET_CURRENT_DESKTOP is set and not 0).
So carefully split out the offending bits and only call them after
the compositor has been initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=731332
