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.
Like in other backends (except X) we can't resize cairo image surfaces
so let's sync the code here with what the other backends do.
This prevents the painting machinery above us to paint on the wrong
buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=724968
We can't destroy buffers if they're in-use by the compositor. Well,
technically we can, but that is considered undefined by Wayland and
mutter won't cope with it very well -- it simply kills the client.
To solve this, we need to delay the destroy operation until the
compositor tells us that it's released the buffer. To do this, hold
an extra ref on the cairo surface as long as the surface is in-use
by the compositor.
This prevents warnings like
(gtk3-demo:14948): Gdk-CRITICAL **: _gdk_frame_clock_thaw: assertion 'GDK_IS_FRAME_CLOCK (clock)' failed
(gtk3-demo:14948): Gdk-CRITICAL **: gdk_frame_clock_get_timings: assertion 'GDK_IS_FRAME_CLOCK (frame_clock)' failed
We need to do this, as the compositor might have already sent us a frame
event, in-flight, at the same time we destroy our window. In this case, we'll
receive the then-in-flight "done" event, and then warn as we try to look
up the frame clock on a destroyed window.
Add a GtkSetting for whether the desktop shell is showing the desktop
folder icons.
This is on by default because most desktop shells do show the icons on
the desktop. We already have a patch in gnome-settings-daemon to bind
this to the org.gnome.desktop.background show-desktop-icons GSettings
key which is off by default on GNOME.
https://bugzilla.gnome.org/show_bug.cgi?id=712302
If a motion event handler (or other handler running from the flush-events
phase of the frame clock) recursed the main loop then flushing wouldn't
complete until after the recursed main loop returned, and various aspects
of the state would get out of sync.
To fix this, change flushing of the event queue to simply mark events as
ready to flush, and let normal event delivery handle the rest.
https://bugzilla.gnome.org/show_bug.cgi?id=705176
Some symbols in the generated Wayland code were getting
decorated with WL_EXPORT, causing them to show up in the
libgdk exports. We don't want that.
https://bugzilla.gnome.org/show_bug.cgi?id=710141
We may get a NULL region passed to the backend, which means
'nothing is opaque'. In that case, don't crash, but pass
the information on to the compositor.
http://bugzilla.gnome.org/show_bug.cgi?id=709854
The surface is destroyed when we hide a window, but
gdk_window_set_opaque_region can be called before the window is
shown again, so we need to ensure the surface exits.
https://bugzilla.gnome.org/show_bug.cgi?id=707328
In the gnome-ostree model builddir contains all generated files not in
git (unless the build system explicitly overrides that). Here the
wayland-client-protocol.h was in $(builddir)/wayland, so we need to
find it using our already extant -I$(top_builddir)/gdk, rather than
relying on same-directory lookup.
Add the concept of shell capabilities, which allow the compositor
to advertise support for the app menu and the global menubar,
which are then propagated as GdkSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=707129
If the compositor supports the gtk-shell interface, use it to
export the application ID, dbus name and paths that can be used
for the application menu.
https://bugzilla.gnome.org/show_bug.cgi?id=707129
This reverts commit b2e666bf8f.
We need to keep cursor blinking configurable for accessibility
reasons.
https://bugzilla.gnome.org/show_bug.cgi?id=704134
Conflicts:
gdk/win32/gdkproperty-win32.c
gdk/x11/gdksettings.c
gtk/gtksettings.c
gtk/gtktextview.c
We want a surface so we can properly represent the scale factor for it.
All backends are converted to use surfaces and we reimplement the
backwards compat code in the generic code.
If we don't dispatch the pending events then we can enter poll with events
still requiring to be processed and which can then lead to us deadlocking
there.
Many parts of GTK+ assume that all windows have a cairo surface
assoicated with them. This change provides a logically 1x1 cairo surface
(respecting scale) for the root window.
https://bugzilla.gnome.org/show_bug.cgi?id=704554
If we bind to a global with an higher version than implemented, or
we make requests that appeared in a later version, we would get
fatal wayland errors.
https://bugzilla.gnome.org/show_bug.cgi?id=704104
With the introduction of the use of buffer scaling in ed4fcee4ct we
must request version 3 of the compositor as that is the version of the
surface interface that adds this new functionality. See the following
commit in weston:
commit a85118c1b85df6fbf8f896dca971a5b79a94da71
Author: Jason Ekstrand <jason@jlekstrand.net>
Date: Thu Jun 27 20:17:02 2013 -0500
Use wl_resource_create() for creating resources
This commit sets the version numbers for all added/created objects. The
wl_compositor.create_surface implementation was altered to create a surface
with the same version as the underlying wl_compositor. Since no other
"child interfaces" have version greater than 1, they were all hard-coded to
version 1.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
https://bugzilla.gnome.org/show_bug.cgi?id=703817
Ths allows the retrieval of the wl_surface before the window is shown.
The surface is still created in the original places since the surface
and shell surface is destroyed when the surface is programmatically
hidden.
We've long had double precision mouse coordinates on wayland (e.g.
when rotating a window) but with the new scaling we even have it on
X (and, its also in Xinput2), so convert all the internal mouse/device
position getters to use doubles and add new accessors for the
public APIs that take doubles instead of ints.
We track the list of outputs each window is on, and set the
scale to the largest scale value of the outputs. Any time the scale
changes we also emit a configure event.
We bind to the newer version of the wl_output which supports
the new done and scale events, and if we use this to get the
scale for each monitor (defaulting to 1 if not supported).
If we got the release event for the last buffer then we're
fine with writing directly to the window surface, as wayland
will not be looing at it. This saves us from allocating
and copying more data.
Change the visibility handling to be the same way we do it in
GLib now. We pass -fvisibility=hidden to gcc and decorate public
functions with __attribute__((visibility("default"))).
This commit just does this for GDK, GTK+ will follow later.
When we call _gdk_wayland_display_load_cursor_theme during
the initial opening of the first display, gdk_setting_get does
not work yet, since it relies on the default display/screen
being set, which only happens after open returns.
Instead, just use the screen of this display.
There is currently no Wayland protocol for providing presentation
timestamps or hints about when drawing will be presented onscreen.
However, by assuming the straightforward algorithm used by the
DRM backend to Weston, we can reverse engineer the right values.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Combine duplicate code for creating and destroying surfaces.
To make the operation of the destroy() operation more obvious, the
destruction of the (fake) root window at display dispose time is
changed to not be a "foreign" destroy.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Use wl_surface_frame() to get notification when the compositor paints
a frame, and use this to throttle drawing to the compositor's refresh
cycle.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Lazily creating the cairo surface that backs a window when we
first paint to it means that the call to
gdk_wayland_window_attach_image() in
gdk_wayland_window_process_updates_recurse() wasn't working the
first time a window was painted.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
When exposing an area, we were individually damaging and committing
each rectangle, *before* drawing. Surprisingly, this almost worked.
Order things right and only commit once.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
