In the Wayland backend implementation for gdk_display_get_keymap we enumerate
the known devices and look for an core keyboard device. These device objects
are created when we receive the capabilities for the seat. The seat
capabilities may be received after a request for the keymap so we handle this
by creating a temporary keymap which we then free later when we have the real
one.
libxkbcommon has had some changes to its API. However, it now has a
stable release (0.2.0), so this makes the necessary changes, and
replaces all uses of the deprecated API.
Signed-off-by: Ran Benita <ran234@gmail.com>
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.
This allows combo box popup windows to appear in the correct place. This is a
workaround emulating root coordinates by calculating the offset for a chain
of windows that that are relative to each other.
Once we've made them popup windows we must also implement the popup_done event
handler on the shell surface listener. The best we can currently do is to hide
the window. This will then signal up to GTK which could then deactivate the
appropriate menu (see https://bugzilla.gnome.org/show_bug.cgi?id=670881)
This allows us to get the device if we need to make the window a popup. This
relies on the side effect that GTK calls into GDK to take a grab before the
popup window is shown.
Move g_return_if_fail() stuff from the backends to the public
functions in gdkscreen.c itself, and some fixes for ugly formatting in
the various gdkscreen-backend.c files.
Due to changes in the behaviour of the virtual modifiers around MOD1 the
implementation of the map_virtual_modifiers vfunc was mangling the modifiers
and making keybindings not work correctly.
This change updates the implementation to match the X11 implementation's
behaviour.
Callers of this function were passing in -1, -1 for the width and height if
they just wanted the window moving - rather than the size changing. We need to
respect that behaviour and don't try and set the width/height to those
dimensions.
Now pop-up windows (ala combo-boxes) work!
When we receive a configure event from Wayland telling us to resize our
surface we check against the geometry constraints for the window to ensure we
do not resize below the minimum and maximum limits.
Now that grab and ungrab vfuncs are implemented on GdkDevice then we can use
gdk_device_ungrab to break the implicit grab created by the button press that
triggered the resize and move.
An implicit grab is created inside GTK+ when the button is pressed down on a
window. The semantics of wl_shell_surface_resize means that you don't get a
corresponding release event that would ordinarily break the implicit grab. So
we must do it as part of the resize request.
This change follows on from a change in semantics in Wayland where calling
wl_input_device_attach with nil would make the compositor set the pointer
sprite to it's default cursor sprite.
The function returns the part of a monitors area that should be
used for positioning popups, menus, etc. The only non-trivial
implementation atm is in the X backend, all the other backends
just return the full monitor area. The X implementation is
currently suboptimal, since it requires roundtrips to collect
the necessary information. It should be changed to monitor
the properties for changes, when XFixes allows to monitor
individual properties.
https://bugzilla.gnome.org/show_bug.cgi?id=641999
Setup listener functions for the drag and drop events as well as the selection
events. Then create and save a data structure representing the data offer from
the other client.
This implementation is based on a hash table. The hard coded GtkSelection
atoms are preloaded into the hash table at the correct values. User generated
atoms start after the last preloaded atom.
