Effectively we have been accepting CurrentTime timestamps for years,
but still complained about "stupid pagers" when encountering them;
just accept that we will never limit treating 0 timestamps as current
time to pagers.
https://bugzilla.gnome.org/show_bug.cgi?id=728018
The code that restacks X11 windows at the end first tracks any
old windows we know about, and then handles any windows created.
It starts when it ended, and then walks forwards and then
back looking for the first X11 window it doesn't know about.
However, when there aren't any X11 windows, it flies off the end
of the array and starts looking through random memory.
When it finds the X11 window, it then goes through and then tries
to restack the remaining windows according to how we've sorted
them.
Unfortunately, META_WINDOW_CLIENT_TYPE_X11 is 0, which is quite
common in random memory we have lying around, so we enter that
path and then just crash.
Fix the buffer overrun by adding the proper bounds check to the
search.
You can easily reproduce this by opening a menu while bloatpad
is full-screen. Why it only crashes when full-screen and not
when a standard window, I have no idea.
The idea here is that while we take a WM-side grab, like a compositor
grab or a resizing grab, we need to remove the focus from the Wayland
client.
We make a special exception for CLICKING operations, because these
are really an internal state machine while you're pressing on a button
inside a frame, and in this case, we need to not kill the focus.
Except while reading _NET_WM_WINDOW_OPACITY, opacity is between 0 and 255. With
guint8, we'll get compiler warnings if arbitrary int values are passed.
https://bugzilla.gnome.org/show_bug.cgi?id=727874
A careful analysis of mutter's codebase shows that nothing actually
passes anything but 0 to this. gnome-shell has one instance, but it's
most likely a mistake.
Remove the grab_mask field and the one place in keybindings.c that uses it.
The parameter to begin_grab_op is left in for API compatibility reasons.
The make_toplevel / window_unmanaging interface has never made
a lot of sense to me. Replace it with set_window, which does
effectively the same thing.
It's still not perfect in the case of XWayland, but I don't think
XWayland will ever make me happy.
Right now this just has all of the files in one directory. We'll
be introducing more structure to this in the future, and build
a proper backend system.
This will allow us to have a MetaCursorReference 'subclass' that's
lazily loaded. We currently always load all the images.
The long-term plan is to have a subclass for each "backend" and only
have CoglTexture as a common denominator. For the nested X11 backend,
we use XDefineCursor on our stage window. For the Wayland backend, we
would use set_cursor on our stage surface. For the native backend, we
would use the GBM code that's there right now.
The CoglTexture is there to be a "shared fallback" between all devices,
and also for the get_sprite API.
The odd man out is the X11 compositor case. For that, we need to move
the responsibility of setting the final cursor image out of
MetaCursorTracker, and simply have it be about tracking the used sprite
image and pointer position.
We want to make this private, and have MetaCursorReference be
backend-defined, with the texture possibly loaded on demand.
We can't make the definition of MetaCursorReference truly private yet
because of the XFixes cursor. A victim of MetaCursorTracker trying to
do too many things at once...
I want the MetaCursorTracker to mostly be about retrieving cursor
information. Start moving the code that loads cursor images to a
new file, MetaCursor. Eventually, MetaCursorTracker's APIs will
all take MetaCursorReferences, and we can have a clean backend
split here.
For whatever reason, this hash table was in the generic
implementation section instead of the XSync implementation,
even though it's only used by the XSync implementation.
Use it as a first pass of things to move over.
The reason we don't simply use gdk_window_add_filter directly is
because of some twisted idea that any GDK symbol being used from
core/ is a layer violation. While we certainly want to keep any
serious GDK code out of ui/, event handling is quite important
to have in core/, so simply use a GDK event filter directly.
Really, visible_to_compositor means that the window is shown, e.g.
not minimized. We need to be using a boolean tracking whether we've
called meta_compositor_add_window / meta_compositor_remove_window.
This fixes a jump during window placement when a window appears.
visible_to_compositor should always be in sync with show_window /
hide_window calls, even when unmananging.
This fixes a crash where we call sync_window_state when the window
is unmanaging, since we use visible_to_compositor to determine whether
the compositor will crash.
This is actually wrong; we should be using the knowledge about
whether we have called add_window / remove_window. We'll introduce
this with a new boolean next time.
Compositors haven't been able to manage more than one screen for
quite a while. Merge MetaCompScreen into MetaCompositor, and update
the API to match.
We still keep MetaScreen in the public compositor API for compatibility
purposes.
We previously separated out MetaDisplay and MetaScreen. mutter
would only manage one screen, but we still kept a list of screens
for simplicity.
With Wayland support, we no longer care about the ability to
manage more than one screen at a time. Remove this by killing
the list of screens, in favor of having just one MetaScreen
in MetaDisplay.
We also kill off active_screen at the same time, since it's
not necessary anymore.
A future cleanup should merge MetaDisplay and MetaScreen. To avoid
breaking API, we should probably keep MetaScreen around as a dummy
type.
When I refactored this out into a vfunc, I forgot to change the
code that interprets the result flags to actually respect the
new FRAME_SHAPE_CHANGED result flag.
Since we weren't ever clearing the frame bounds, this meant that
the "shadow clip" wasn't ever updated as a result. Since right now
all Wayland surfaces are considered ARGB32, we always clip shadows
under frames, and thus shadows had this weird "punch-out" from the
first frame shape.
