Before, we were using the root window coordinates of the client window,
rather than the toplevel frame window. This caused various Java programs
and programs like VirtualBox and WINE to get confused about where their
window actually is, and make bad ConfigureRequests when trying to
position their windows in the future.
Remove the mass of code here by just using window->rect.
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.
MetaGrabOp is painful and tedious to work with, because it's a
sequential series of values, meaning we have to use a giant unreadable
switch statement to figure out some basic things about the value.
To solve this, modify the encoding for MetaGrabOp and for the specific
window grab operations so that they're a set of bitflags that we can
easily check.
We've long used a switch statement on the grab operation to determine
where events should go. The issue with MetaGrabOp is that it's a mixture
of a few different things, including event routing, state management,
and the behavior to choose during operations.
This leads to poorly defined event routing and hard-to-follow logic,
since it's sometimes unclear what should point where, and our utility
methods for determining grab operations apart can be poorly named.
To fix this, establish the concept of a "event route", which describes
where events should be routed to.
It turns out that Clutter doesn't actually filter NumLock / ScrollLock /
CapsLock from button events due to its terrible event translation code.
Check only the grab mods to check if it's unmodified.
Popups could not set the cursor image, because the cursor tracker would
ignore window cursors if we had a popup active. The correct condition to
check for is already in should_block_wayland. Rename this to the more
sensible name windows_are_interactable, and use it in the cursor tracker.
Since commit 467465c99c we use meta_stage even on x11 which sets
clutter_stage_set_user_resizable to FALSE.
This messes things up because we ought to ignore the properties on the window
but we apperently didn't.
There is no reason why we'd want to manage the stage window.
https://bugzilla.gnome.org/show_bug.cgi?id=734852
Instead of returning a value based on whether or not we handled it, we
have this logic: either we have taken a grab on the window, in which
case we have a grab op and have handled it ourselves, or we did not take
a grab and *need* to replay the event to the window.
Handle this in events.c by checking the grab operation in the same way
that we check the other grab ops.
This is an accidental regression from 7a109a1. If we mark the event as
handled, then we *need* to set grab_op, or do some other sort of
behavior, since we have a grab.
meta_backend_get_keymap is supposed to return a static keymap, not a new
one every time. Cache it internally. We don't update it when the keymap
changes on the server, but we'll do this soon.
Now that we always use XKB, it's very unlikely that we'll get a
MappingNotifier without a subsequence XkbKeymapNotify event. Just
do all the work always.
This will also help us considerably for the future when we'll be
putting the keymap event in the backend.
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.
Mutter depends on the X11 windowing backend of Clutter, unless it's used
as a Wayland display server.
This allows Mutter to run without breaking in case Clutter changes the
order with which windowing backends are selected, like it was the case
for bug https://bugzilla.gnome.org/show_bug.cgi?id=734587
The order of selection of the Clutter backends has not been made public,
so it cannot be relied upon since the introduction of the multiple
backends support; since Mutter requires the X11 backend functionality,
it should select the X11 windowing system, in the same way it selects
the EGL backend when compiled and run as a Wayland display server.
If we for some reason have an error trying to allocate the framebuffer,
we'll still mark the tower as revalidated. Move the validation to the
end of the actual revalidation code to solve this.
It's a deprecated API that can surprise us. Namely, when the internal
format passed is COGL_PIXEL_FORMAT_ANY, it will *always* allocate an
RGBA8888 pixel format texture, even if we only passed it a RGB format
or even an A8 format.
cogl_texture_2d_new_with_data is the newer, better API and doesn't have
these warts.
These methods allow us to set and get xkbcommon keymaps as well as
locking a specific layout in a layout group.
With this, we introduce dependencies on xkeyboard-config, xkbfile,
xkbcommon-x11 and a libX11 new enough to have xcb support.
https://bugzilla.gnome.org/show_bug.cgi?id=734301
At this point there shouldn't be any system capable of running mutter
that doesn't have it and we're introducing functionality like setting
the keymap that has an hard requirement on it.
https://bugzilla.gnome.org/show_bug.cgi?id=734301
Since commit a7b7213017, we rely on the standard property
system to initialize the window type (and likewise for the window
role since commit 031154a400). However as property hooks are
never run for properties that are not set, we end up not initializing
the window type correctly for windows with no _NET_WM_WINDOW_TYPE
property (which includes virtually all OR windows, causing them to
show up in pagers and the Shell overview and resulting in frequent
crashes due to breaking reasonable assumptions all over the place).
Introduce a new FORCE_INIT flag to allow forcing hooks to run
even when the corresponding property is unset, and use it for
both _NET_WM_WINDOW_TYPE and _NET_WM_WINDOW_ROLE.
This way the xserver never paints the frame background, even if
the client window is destroyed. This allows us to have clean
destroy window animation.
There is no problem with interactive resizing because applications
are using the XSync protocol, so we're not painting unless the
client has redrawn.
https://bugzilla.gnome.org/show_bug.cgi?id=734054
Connecting to size-changed is wrong -- size-changed tells us when
we *told* the X server or resize the window. For X11, we're sort of
guaranteed that the surface will be updated at some point before the
next frame, but for Xwayland, we can't be sure that the new surface is
attached at this point.
This fixes weird artifacts when resizing apps like xclock.
This was wrong for subsurfaces that extend beyond the parent's shape,
since the paint volume would be wrong in this case. Instead of using the
shape region which can be out of date and wrong, just use the union of
our children's volumes, which is a lot easier to manage.
Refuse to create a touch resource if we don't have the capability
(for misbehaving clients), and don't attempt to use touch data
structures that are not initialized.
This is a terrible hack. We need to figure out a better way to do
interactive resizes.
This fixes weird resizing from the left bugs when using GTK+, which is
really slow at acking configures.
This is an easy way to get into an infinite loop where we're constantly
re-sending stuff to the window. If it worked once, it probably won't
work again.
We assume in meta_window_wayland_move_resize that the next commit that
changes the geometry will always be for our next pending operation, so
if we have a move pending on a resize, the next commit will trigger the
move. This is, of course, fundamentally wrong.
We broke this assumption even more now that we don't fizzle out calls to
meta_window_move_resize_internal and now call it on every commit, which
means that a simple damage and then commit would complete a pending
move.
This was even broken by apps like weston-terminal, which, when clicking
on the maximize button, first redraws the terminal with the maximize
button state back on hover on press, and would only redraw when it got
the configure event with the coordinates.
To track the correct commit to apply the move for, we implement the
ack_configure request and ignore all move/resizes that happen before
that.
Right now, we actually fizzle out the entire move/resize if there's a
future pending configure we're waiting on.
Sometimes we can get a host event without having the display up and
running yet. Just don't pass it to the compositor in that case, since it
won't be possible for it to have any event that matters.
MetaGestureTracker has been separating the "did I handle an event?" and the
"should the event be filtered out?" questions, merge this and make
handle_event() reply to "should the event be only handled by me?".
If a sequence wasn't accepted yet by the gesture tracker, the event will
go through (eg. not handled exclusively by the gesture tracker) and it'll
still be processed by Clutter, triggering gesture actions, and maybe
changing the sequence into other state.
https://bugzilla.gnome.org/show_bug.cgi?id=733631
The grabbing state is now checked for both pointer/touch devices
within the seat, and the grab start coordinates returned by
meta_wayland_seat_get_grab_info().
https://bugzilla.gnome.org/show_bug.cgi?id=733631
On X11 this works because only emulated pointer events are listened for. On
wayland, the single touch behavior must be enforced in touch events, ignoring
every other sequence.
https://bugzilla.gnome.org/show_bug.cgi?id=733631
This function tells the obvious on X11, and implements a similar mechanism
on wayland to determine the "pointer emulating" sequence, or one to stick
with when implementing single-touch behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=733631
Due to the way the MetaGestureTracker processes every touch event, this
will tell as closely to Clutter as possible the current number of touches
happening on the stage.
Even though, this is subject to windowing behavior, on X11, rejected touches
will be soon followed by a XI_TouchEnd event, so the compositor will stop
seeing touch sequences that are still operating on clients. On wayland, touch
sequences are processed by the compositor during all their lifetime, so these
will stay on the MetaGestureTracker with META_SEQUENCE_PENDING_END state, yet
still tracked.
https://bugzilla.gnome.org/show_bug.cgi?id=733631
On wayland, touches are initially both handled by the compositor and sent
to clients, proceeding to cancellation on clients only after the compositor
claims the sequence for itself. Implement the cancellation detail through
MetaGestureTracker::state-changed.
https://bugzilla.gnome.org/show_bug.cgi?id=733631
