We need to do this here so that an explicit gtk_widget_destroy
on either the widget or a container that holds it will kill the
reference to the menu or model.
https://bugzilla.gnome.org/show_bug.cgi?id=680803
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
These are just wrappers for the functions, and we want to
deprecate them. Stopping to use them internally is a good
first step. Also define GTK_COMPILATION so we can keep using
gdk_threads_enter/leave without causing deprecation warnings.
Remove the "-win32-" from the output file names for the GDK and GTK+ DLLs,
like what is now done for quite a while on other platforms
(and MinGW builds), for consistency reasons. This is due to GDK/GTK+
are buildable with multiple backends.
Note: For references, the Windows build only builds the Win32 backend
for the time being.
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.
We now support independent selection and primary clipboards, and avoid
wiping clipboard on modifying its contents from the same owner. This fixes
most of the interaction issues with clipboard and selection.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
GSequence iterators point at the position between two elements so an
iterator pointing at the N tree model node is actually between the N-1
and N sequence elements. This means that asking for the previous
sequence iterator first and then checking if it is the begin iterator
would yeld true for an iterator pointing at the 2nd tree model node
and make us return FALSE mistakenly.
https://bugzilla.gnome.org/show_bug.cgi?id=679910
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>
This program launches an application specified by its desktop name
optinally taking list of URIs which are passed as arguments.
Uses GdkAppLaunchContext to get proper startup notification and
display handling for graphical apps.
https://bugzilla.gnome.org/show_bug.cgi?id=679342
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>
