Avoid copying back partially drawn double-buffer data
when flushing to avoid flicker. This means non double
buffered widgets must draw opaque pixels in its expose
handlers, and that you are not allowed to use direct
rendering (or modify GdkWindow pos/size/order) from
inside the expose handler of a double buffered widget.
See https://bugzilla.gnome.org/show_bug.cgi?id=679144 for more
details
The code was calling _gdk_window_ref_cairo_surface in a few places
where the intent was not to read/write to the surface, but just look
at its type (to e.g. create a similar surface). This is bad, as that
operation causes a flush which may cause unnecessary work and/or
flashing. Instead we just get the impl surface in these cases.
get_time_from_ns_event(): apply patch from Michael Hutchinson which
makes sure the returned guint32 wraps correctly on 32 bit machines
when the uptime exceeds 2^32 ms.
Not defining these macros at all causes harsh build breakages.
Better to leave them defined (but documented as deprecated) for now.
Everybody will still get the deprecation warnings for the underlying
gdk_threads_enter/leave.
We can hide the macros again later on when the world has had some
time to port off GDK threads.
The story is slightly different for applications vs libraries;
make it clear that libraries should continue using the lock so
we don't break applications that haven't been ported to the
'single thread' model yet.
This commit deprecates gdk_threads_init, gdk_threads_enter,
gdk_threads_leave and gdk_threads_set_lock_functions. Using GTK+
from multiple threads does not work at all on Windows, and is
problematic on other platforms as well. We want to move to a world
where all GTK+ calls are made from the main thread.
Use g_main_context_invoke, g_idle_add and related functions if you
need to schedule GTK+ calls from other threads.
http://bugzilla.gnome.org/show_bug.cgi?id=680754
If we don't have a wl_seat - because a grab hasn't been initialised by GTK+
then fallback to making the shell surface transient to the parent rather than
a popup surface.
Review comment: I think the implementation of the vfuncs in gdkkeys-wayland.c
depend on that we're using the keysysm as the hardware keycode. I think that
needs to be evaluated for the future. But for now this patch gives reasonably
complete keyboard input.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
This is then logically associated with the input device since each (keyboard)
input device has its own keymap.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
Although GDK expects the keymap to be associated with the display under
Wayland this is really associated with the input device so expose this by
finding the first keyboard device.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
We translate wayland pointer axis events to GDK smooth scroll events, to
implement pointer_handle_axis events.
https://bugzilla.gnome.org/show_bug.cgi?id=679986
Signed-off-by: Rob Bradford <rob@linux.intel.com>
This replaces the wl_input_device with wl_pointer, wl_keyboard, wl_touch all
tied together under a wl_seat.
This is quite a radical change in protocol and for now keyboard handling is
disabled.
This requires the SHM object be initialised - therefore this is the most
logical (if slightly ugly place.)
We also need to make sure that we do something clever to load the correct
cursor theme.
Don't use ASCII control characters to denote the input of Esc, Tab,
Return/Enter, Backspace and Delete, as it seems that it is not how
Windows handle them, and they cause weird characters to appear in the
input field on GTK+3 programs in non-English Windows. Instead, let
these keys be handled as-is on Windows, like what is done in GTK+-2.x.
Checked with mclasen on IRC, and thanks to the people who verified the
patch to not break anything on English Windows.
gdk_device_list_slave_devices only makes sense to call on master
devices, yet its g_return_if_fail check made it reject such devices.
Pointed out by monty.
