Windows that set empty input shapes get n_rects of 0 when querying them
later, which makes sense, but the code that interpreted the result
translated it into a NULL input shape, which meant it was the same as
the bounding region. As such, an empty input shape would actually get
interpreted as a full input shape!
We, ourselves, set an empty input shape on tray icon windows in
gnome-shell since we would handle the picking ourselves. This meant that
we'd actually get the MetaSurfaceActorX11 when hovering over the tray
icon, instead of the ShellGTKEmbed that we capture events on and react
to.
This fixes weird tray icon behavior in gnome-shell.
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
WindowActors can outlive their corresponding window to animate unmap.
Unredirecting the actor does not make sense in that case, so make
sure to not request it.
https://bugzilla.gnome.org/show_bug.cgi?id=740133
Whoops, I made the code work without it, but forgot to strip it from the
actual list of requires packages.
Spotted-by: Rico Tzschichholz <ricotz@ubuntu.com>
meta_monitor_config_match_current() only matches the number of outputs
and if the output connector, vendor, product and serial match.
This means that we can't use it to bypass doing any
work because it won't detect cases where we actually want to update
ourselves like e.g. an output being turned off either by us or by
another X client (e.g. xrandr).
https://bugzilla.gnome.org/show_bug.cgi?id=738630
When a laptop's lid is closed we try to build and apply a temporary
configuration that disables the laptop's display if we have other
outputs.
This isn't enough though, we must also check if at least one of these
other outputs is enabled otherwise we'll try to resize the screen to
0x0 which (rightfully) hits an assertion.
https://bugzilla.gnome.org/show_bug.cgi?id=739450
The input region currently only gets scaled by the surface
scale while ignoring the output scale, which causes input events to not get
delivered correctly for clients on hidpi screens. So take the output scale
into account when doing so.
https://bugzilla.gnome.org/show_bug.cgi?id=739161
This commit is wrong, it assumes that the scale only applies to the one
set by the client but its not. meta_surface_actor_wayland_scale_texture
also handles the output scale. Revert the commit to fix hidpi for wayland
clients like weston-terminal.
This reverts commit 0364ea9140.
https://bugzilla.gnome.org/show_bug.cgi?id=739161
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
We clip the input region to the client rect, so the client rect should
be up to date before we fetch the input region.
This fixes popup windows not working in GTK+2 under Wayland.
We should also update the shape / input regions when the window is
reconfigured for a complete fix, so that making an O-R window bigger
doesn't confuse mutter, but let's leave that to a future commit.
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
Damage coordinates are relative to the drawable not to the screen. So we
have to check whether x and y are 0 and not window_rect.x/y otherwise the
herustic will never trigger for windows on monitors whos x and y are not 0.
https://bugzilla.gnome.org/show_bug.cgi?id=738271
The key event should be interpreted by clients with the modifier state
as it was before the event itself just as in X11 input events.
Achieving this in wayland is a matter of sending the key event first
and the modifiers after (if needed).
This isn't really specified in the wayland protocol but it matches
weston's behavior and should avoid corner cases in clients.
https://bugzilla.gnome.org/show_bug.cgi?id=738238
This reverts commit 33acb5fea0.
The issue here is that the pointer actor does not actually get reset
when the actor's reactivity changes, so we end up with stale picks after
actors are destroyed.
I have a local patch to Clutter for this, but I don't have time to
submit it upstream, so let's just use the ugly code for now.
This reverts commit e496ed50d6.
This was incorrect. wl_surface_destructor actually does the full repick
-- doing it here is dangerous, because the destroy listeners actually
run *before* the destructor, not after, so the surface is still alive.
We never want to send pressed keys to wayland clients on enter. The
protocol says that we should send them, presumably so that clients can
trigger their own key repeat routine in case they are given focus and
a key is physically pressed.
Unfortunately this causes some clients, in particular Xwayland, to
register key events that they really shouldn't handle, e.g. on an
Alt+Tab keybinding, where Alt is released before Tab, clients would
see Tab being pressed on enter followed by a key release event for
Tab, meaning that Tab would be processed by the client when it really
shouldn't.
Since the use case for the pressed keys array on enter seems weak to
us, we'll just fake that there are no pressed keys instead which
should be spec compliant even if it might not be true.
https://bugzilla.gnome.org/show_bug.cgi?id=727178
It only contained a pointer to a wl_resource, which isn't much of
value. Just replace it with the wl_resource instead. Any future private
data should be handled by our future role system.
