Only static cursors are supported in gdk_device_grab() so far. Obey the
cursor that gdk_device_grab() specifies, which may be different to
the pointer window one. As soon as the grab is gone, the pointer window
cursor will be restored as usual.
https://bugzilla.gnome.org/show_bug.cgi?id=735831
On DnD, pointer_handle_leave may be triggered without the pointer actually
leaving the window, and pointer_handle_enter() happening after intra-window
DnD won't actually manage to update the cursor (it does nothing directly,
and to the upper layers the cursor is still the same and consistent, so no
attempt will happen).
To fix this, keep the pointer cursor on leave, and ensure it is updated
on enter. The pointer cursor will be updated to any current new one through
the enter/motion events generated if it needs be.
https://bugzilla.gnome.org/show_bug.cgi?id=735831
cairo_surface_destroy() is called after the buffer is released, for every
wl_buffer. Windows usually reference their cairo surface before rendering,
so that extra reference is consumed after the buffer is released, so do
the same with cursor surfaces and add an extra reference whenever a cursor
surface change is about to be scheduled.
Otherwise, the GdkWaylandCursor is left with an invalid cairo_surface_t,
which causes crashes the next time it is used.
https://bugzilla.gnome.org/show_bug.cgi?id=735830
On wayland the DnD surface must be created early when starting the drag
operation, so offer API for GTK+ to get the GdkWindow used as a DnD
surface on the drag operation.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
The wl_data_source is retrieved from the selection object for the DnD
selection, and used to initiate a drag. When the drag is finished, a
button release or touch end event is synthesized to finish the DnD
operation after the compositor grab is gone.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
The wayland specific clipboard functions have been replaced by something
more similar to the hooking the win32 backend does, which allows for just
using the default GtkClipboard code in GTK+. As a consequence, the
wayland-specific GtkClipboard implementation is now gone.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
This has been made to work similarly to X11, requests for the data device
contents are notified through GDK_SELECTION_REQUEST events, the data stored
in the GDK_SELECTION property as a reaction to that event is then stored
into the wayland selection implementation, and written to the fd when
requested/available.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
This implementation makes the destination side of selections work
similarly to X11's, gdk_selection_convert() triggers data fetching,
which is notified through GDK_SELECTION_NOTIFY events on arrival,
the buffered data is then available through gdk_selection_property_get().
https://bugzilla.gnome.org/show_bug.cgi?id=697855
Subsurface position is deemed part of the state of the parent surface, so
ensure wl_surface_commit() happens on the parent surface if none is
scheduled, so the repositioning takes place.
The latest implicit grab serial is used in order to start the compositor
grab, If it belongs to a touch event, remove that touch sequence, as the
rest of the sequence will be gone for good.
This avoids stale sequences (and implicit grab info) after a window is
moved/resized.
https://bugzilla.gnome.org/show_bug.cgi?id=731380
_gdk_wayland_device_get_button_press_serial() has been replaced by
_gdk_wayland_device_get_implicit_grab_serial(), which takes a touch/pointer
event and figures out the relevant serial, and
_gdk_wayland_device_get_last_implicit_grab_serial() which returns
the most recent serial.
The button press serial was currently used when operating popping up
xdg_shell/surface popups and window menus, so this is now touch aware, of
some sort.
https://bugzilla.gnome.org/show_bug.cgi?id=734374
If the compositor sends a keymap that fails on "compilation",
xkb_keymap_new_from_string() returns NULL, which makes xkb_state_new()
crash when assuming there is a keymap.
In these cases, gdk must remain with a xkb_state to handle modifiers/keys
properly, so warn about the invalid keymap string, and keep the previous
keymap (currently initialized to "us")
https://bugzilla.gnome.org/show_bug.cgi?id=735389
To all effects each window has its own "root" coordinates system, so set
toplevels at 0,0 in that coordinate system, so root coordinate calculations
are locally right.
https://bugzilla.gnome.org/show_bug.cgi?id=729215
Delay the keyboard settings creation until we're delivering the key
press. This means we don't have to create the settings for a server that
sends us repeat information.
xdg-shell has moved on and replaced set_margin with set_window_geometry.
To properly support set_window_geometry requires a full rewrite of how
we've been dealing with toplevel windows for now, so just don't set any
margin until we can have a proper toplevel window abstraction in GTK+.
gdk_x11_display_set_window_scale() affects the interpretation of the
Xft/DPI XSETTING - it is substituted inside GDK with the value of
Gdk/UnscaledDPI xsetting. However, this change is not propagated to
GTK+ and from GTK+ back to gdk_screen_set_resolution() until the
main loop is run.
Fix this by handling the screen resolution directly in gdk/x11.
This requires duplication of code between GDK and GTK+ since we still
have to handle DPI in GTK+ in the case that GdkSettings:gtk-xft-dpi
is set by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=733076
The way that GtkTextView et al pop up their context menu is to first
query to see if the clipboard has some text, and if so, enable the Paste
menu item. But since the Wayland backend hasn't had the greatest
selection and clipboard code, the callback for the clipboard got dropped
on the floor.
Add some simple code to respond to the TARGETS selection.
This makes right-clicking on a GtkTextView work fine.
Traditionally, the way painting was done in GTK+ was with the
"expose-event" handler, where you'd use GDK methods to do drawing on
your surface. In GTK+ 2.24, we added cairo support with gdk_cairo_create,
so you could paint your graphics with cairo.
Since then, we've added client-side windows, double buffering, the paint
clock, and various other enhancements, and the modern way to do drawing
is to connect to the "draw" signal on GtkWidget, which hands you a
cairo_t. To do double-buffering, the cairo_t we hand you is actually on
a secret surface, not the actual backing store of the window, and when
the draw handler completes we blit it into the main backing store
atomically.
The code to do this is with the APIs gdk_window_begin_paint_region,
which creates the temporary surface, and gdk_window_end_paint which
blits it back into the backing store. GTK+'s implementation of the
"draw" signal uses these APIs.
We've always sort-of supported people calling gdk_cairo_create
"outside" of a begin_paint / end_paint like old times, but then you're
not getting the benefit of double-buffering, and it's harder for GDK to
optimize.
Additionally, newer backends like Mir and Wayland can't actually support
this model, since they're based on double-buffering and swapping buffers
at various points in time. If we hand you a random cairo_t, we have no
idea when is a good time to swap.
Remove support for this.
This is technically a GDK API break: a warning is added in cases where
gdk_cairo_create is called outside of a paint cycle, and the returned
surface is a dummy that won't ever be composited back onto the main
surface. Testing with complex applications like Ardour didn't produce
any warnings.
Weston releases buffers almost immediately after they're done, which
means that GTK+ doesn't use a temporary surface and instead paints
directly onto the SHM backing store that Weston will use.
Normally, after painting to the temporary surface, GTK+ *replaces*
the existing backing surface with CAIRO_OPERATOR_SOURCE. However,
if we immediately paint to the backing surface, it might have junk
from the last paint in it. So clear out the backing surface whenever
somebody calls begin_paint_region().
Maybe we should just always use the temporary surface like the X11
codepath, since that prevents us from having to do weird things like
this, but oh well.
wl_surfaces can't switch roles, so destroying the xdg_surface but not
the wl_surface means that we could get an error when trying to re-map
the surface.
We could fix this by not destroying the xdg resource and only do it at
finalization time, but it's just as easy to just create a new wl_surface.
Since the xdg roles are a special case of the surface, some compositors
like Weston destroy them automatically when the wl_surface is destroyed.
Thus, we need to destroy these first.
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.
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).
