We do not know what happened to this surface outside of GDK.
Especially for foreign windows, they will have been modified
by external applications.
So be on the safe side and tell Cairo to clear all its caches.
https://bugzilla.gnome.org/show_bug.cgi?id=754952
gdk_wayland_device_update_window_cursor() is inconsistently returning
TRUE/FALSE, despite the timeout being always replaced for new cursor
frames. This could end up in these timeouts being "leaked" and running
as long as the window has an animated cursor.
Fix this by making it really sure we return G_SOURCE_REMOVE, although
now we keep track of animation delays, so the timeout will be reused
for constant time animations.
We need to rename the projects so that when these projects are added
into an all-in-one solution file that will build the GTK+ 2/3 stack,
the names of the projects will not collide with the GTK+-2.x ones,
especially as GTK+-2.x and GTK+-3.x are done to co-exist on the same
system. This is due to the case that the MSVC projects are directly
carried over from the GTK+-2.x ones and was then updated for 3.x.
We still need to update the GUIDs of the projects, so that they won't
conflict with the GTK+-2.x ones.
Use the common automake module from the previous commit in the
Makefile.am's, which means that the Makefile.am's in gdk/ and gtk/ can be
cleaned up as a result. As a side effect, the property sheet that is used
to "install" the build results and headers can now be generated in terms of
the listing of headers to copy during 'make dist', where we can acquire
most of the list of headers to "install", so that we can largely avoid the
situation where the property sheet files are not updated in time for this,
causing missing headers when this build of GTK+ is being used.
Also use the Visual Studio Project file generation for the following
projects:
gtk3-demo
gtk3-demo-application
gtk3-icon-browser
gdk-win32
gdk-broadway
gail-util
So that the maintenace of these project files can be simplified as well.
https://bugzilla.gnome.org/show_bug.cgi?id=681965
Initially the subsurface will be in synchronized mode and we will leave
it like this until the first time the parent surface has been committed.
The reason for this is because the subsurface position will be applied
as part of the parent surface state, and we need to synchronize the
initial position with the initial frame, so that we don't accidentally
draw the subsurface at the default position (0, 0) which would happen in
desynchronized mode if the subsurface content is committed before the
next parent surface commit.
https://bugzilla.gnome.org/show_bug.cgi?id=754839
There is no need to ref the windows we're ignoring, so collect and ref
only the affected child windows. Also, use a on-stack array rather
than allocating a linked list.
Also, we don't need to ref during the event emissions too, as we
already hold a ref.
https://bugzilla.gnome.org/show_bug.cgi?id=754687
This avoids a bunch of allocations, and additionally it has better
cache behaviour, as we don't follow pointers to the separate GList
node memory areas during traversal.
From Christian Hergert:
This machine is a Retina mac book pro so I've been working on getting
GtkTextView (GtkPixelCache) up to our performance level on
X11/Wayland. I'm seeing a jump from about 43 FPS to about 50 FPS.
https://bugzilla.gnome.org/show_bug.cgi?id=754687
Otherwise the outer loop control variable is messed up, and we end
up with uninitialized axes if there were any more valuators after
the XIKeyClass one.
This bug was sneakily introduced by fdb9a8e14, many thanks to
Carlos Soriano for helping spot the source of this bug.
https://bugzilla.gnome.org/show_bug.cgi?id=753431
If we are using gl for drawing, we don't have a shm surface,
so don't assert that we do. Instead, only call shm-specific
apis when they make sense.
This fixes a crash when showing popovers over a GtkGLArea,
as seen in gdkgears.
https://bugzilla.gnome.org/show_bug.cgi?id=754143
When receiving a selection or when a drag icon enter a window, it was
targeted at a specific window. Lets emit the GDK_OWNER_CHANGE event
only for this window, instead of broadcasting.
Broadcasting has some nasty side effects. For example, if there was n
GdkWindows, and one would for every "owner-change" signal handler
receive n signals about the owner being changed.
An example of where this went a bit out of hand was gnome-terminal,
which added one listener per terminal window. This meant that if
one had m number of terminal windows, each time any one would loose or
gain keyboard focus, O(m^2) owner-change events would be emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=754158
The code in _gdk_wayland_window_dispose was not safe against
being called twice - it would call g_hash_table_destroy twice
on the known_globals hash table, the second time operating on
freed memory. It was also leaking the list of async_roundtrips.
After fixing both of these issues, the displayclose testcase
now works on Wayland.
We call gdk_wayland_window_hide_surface when the window gets
destroyed, and in this case, the frame clock might not exist
anymore.
This was showing up in the displayclose testcase.
While we do not have subwindows in Wayland, we do create an
artificial root window. When the display is closed, the root
window gets destroyed, causing recursing to be true for the
toplevel windows.
As the protocol is still considered unstable (meaning not backward
compatible), we should, as stated in the protocol, only bind the version
advertised is the version we implement.
https://bugzilla.gnome.org/show_bug.cgi?id=753856
The extra reference will be held from GdkEventPrivate data, so there's
a common place to all events. Without this, events queued after devices/
capabilities disappear (eg. on TTY switch) might hold invalid pointers.
Windowing level operations on those devices (queries, grabs...) are
expected to fail at that time, but we should hold meaningful data for
the regular event handling paths.
https://bugzilla.gnome.org/show_bug.cgi?id=753185
Prior to this patch, the ID of the GtkApplication was always used for
clients which were GtkApplications. This would only be guaranteed to be
correct for D-Bus activatable programs. As a result, all
non-D-Bus-activatable applications would set the wrong ID making the
shell unable to find the corresponding .desktop file.
This change makes it so that the GDK backend always uses the name
passed to g_set_prgname, or the default value if not explicitly set, as
this more often corresponds to the .desktop file.
This means that in order to make D-Bus activatable applications set the
correct application ID, they must, for now, manually call
g_set_prgname() with their application ID (basename of the .desktop
file).
If g_get_prgname() returns NULL, fallback to gdk_get_program_class()
even though it will most likely never be correct according to the
xdg_surface.set_app_id specification.
https://bugzilla.gnome.org/show_bug.cgi?id=746435
wl_log() currently logs using G_LOG_LEVEL_ERROR
(which is fatal). The wayland client library doesn't
expect this behavior. It uses wl_log to log recoverable
errors.
This commit changes the log level to G_LOG_LEVEL_DEBUG
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=753635
On wayland, the gestures protocol defines a wl_pointer_gestures global
object, that will match in number with wl_seats, swipe and pinch
interfaces can be obtained from it, which events are translated into
GdkEventTouchpadSwipe/Pinch events.
Each gesture type has its separate GdkEvent struct, and begin/update/
end/cancel event types.
There is support for multi-finger swipe (3-4 fingers), and 2-finger
rotate/pinch gestures.
Only a drag context which was created with 'drag_begin' will be
guaranteed to have a source window at all times. Thus, in finalize we
cannot assume we can retrieve a GdkDisplay from the source_window
pointer since it may be NULL. Though, the display is only needed for
contexts created via 'drag_begin' thus we can retrieve it after
checking that is the case.
https://bugzilla.gnome.org/show_bug.cgi?id=749339
We need to be mapped to have a gtk_surface and thus be able to do
requests on it so we need to save the modal hint and apply it when we
get mapped so that code that sets the hint before showing a window
doesn't get ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=753138
When dealing with selection events, we might see windows from
other screens in the requestor field. The current x11 backend
code fails to wrap these in a foreign GdkWindow, since we
don't have the corresponding GdkScreen anymore. Work around
this by creating such 'foreign screens' on demand. We still
maintain the 1:1 relation between the display and the screen
returned by gdk_display_get_default_screen().
https://bugzilla.gnome.org/show_bug.cgi?id=721398
