The Wayland compositor is completely allowed to send us configure
events for the same size, and this validly happens if we're changing
states. Fizzle these out.
Weston numbers its touch sequences ids starting from 0, thus simply
setting the GtkEvents touch.sequence to the touch id value typically
causes gdk_event_get_event_sequence to return NULL. Unfortunately this
confuses other parts of GDK.
As both weston & mutter keep the sequence id between 0..max_dev_touches
-1 simply use + 1 to keep the id > 0. While this isn't entirely correct
(compositor could send -1 as the touch id), this keeps the touch id in
gtk tied to the touch id from weston which is useful for debugging. A
more thorough solution could be done when it turns out this is an issue
in practise
https://bugzilla.gnome.org/show_bug.cgi?id=731371
There are plans to add session-dependent defaults to GSettings
(based on the newly standardized XDG_CURRENT_DESKTOP); until
then, the WM uses a different schema for its button-layout
setting in classic mode. So for the time being, do the same
and pick the alternative schema when XDG_CURRENT_DESKTOP
indicates that we are in a classic session.
(It's not pretty, but hopefully won't be with us for too long ...)
https://bugzilla.gnome.org/show_bug.cgi?id=731273
Pick up the setting from the org.gnome.desktop.wm.preferences schema
if available. It is slightly more involved than other settings, as
the actual button names used in the schema differ from the ones we
use, so we need an additional translation step.
https://bugzilla.gnome.org/show_bug.cgi?id=731273
All the globals we care about should appear before doing anything
else, up-front, so a single round-trip after adding the registry
should be more than enough.
Since you can't take grabs on unmapped windows, GtkMenu takes a grab on
the menu in a convoluted way: it first grabs another window, shows the
menu window, and then transfers the grab over to the GtkMenu widget.
For normal menubars, this is perfectly fine, as the first window it grabs
is our toplevel, and that gets picked up in our transient path. For
GtkMenuButton or other spurious uses of gtk_menu_popup, it creates a new
temporary input-only window which it takes the grab on, known as the "grab
transfer window". Since this window isn't a transient-for of our new menu
widget window, the grab isn't noticed when we go to show it, and thus the
menu ends up as a new toplevel.
Add a special hack to GtkMenu and the Wayland backend which lets us notice
this "grab transfer window", and include it in our grab finding path.
It's sort of terrible to have to hack up the widgets instead of just the
backend, but the alternative would be an entirely new window type which is
managed correctly by GDK. I don't want to write that.
The events are routed through a new slave device with type
GDK_SOURCE_TOUCHSCREEN, minimal tracking of touches is done
to keep the state for each of those.
https://bugzilla.gnome.org/show_bug.cgi?id=728426
The master pointer/keyboard pair should never disappear or be
inconsistent. The seat capabilities are now reflected through
slave devices, those may come and go freely as the seat
capabilities change. This also enables adding further capabilities
to handle eg. touch.
https://bugzilla.gnome.org/show_bug.cgi?id=728426
The compositing that is meant here is really specific to the
X11 Composite extension, and does not apply to Wayland.
This is very rarely used functionality anyway, and none of
the other backends support it.
Theoretically, we apply the shape mask client-side ourselves
with an ARGB32 pixmap and intersect it to get a union shape,
but I don't particularly care enough to write that code.
Realistic application code using bounding shapes in 2014 is
quite rare.
It seems that some backends implemented get_root_origin wrong
and returned the client window coordinates, not the frame window
coordinates. Since it's possible to implement generically for all
windows, let's do that instead of having a separate impl vfunc.
Lots of code, including dragging code in GtkWindow, use these
fields. Setting them to 0 causes lots of strange and weird bugs.
Use the same "hack" from query_device_state of just using
win_x / win_y for now. We'll convert this to the proper fake root
coordinate system used by get_root_coords in the next commit.
window->x / window->y are in "root window coordinates", e.g. relative
to the topmost toplevel. However, the coordinates in get_xdg_popup are
relative to the passed-in surface, so we need to do the reverse
translation here.
GtkWindow calls set_shadow_width then maps the window, meaning
that we never set the margin. Save it when we set and then set
it when we create the XDG surface.
Instead of destroying the surface in the backend if this is
unable to resize, let the core code do it, and do it properly.
Based on a patch by Benjamin Otte.
https://bugzilla.gnome.org/show_bug.cgi?id=725172
The code in GDK is incredibly broken and nobody is quite sure what's
right-side-up and what's upside down, but this breaks mutter-wayland
now, so let's remove it. It might leak, but we should probably do a
full restructuring of GDK drawing to fix it.
