The code for handling key repeats (and in particular stopping on focus loss)
assumes that the repeat key is set to XKB_KEYCODE_INVALID in the default case.
This change switches to the new mechanism for loading a cursor into a buffer.
It no longer relies on having a PNG stored in a known location and instead
loads from the Wayland cursor theme.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
Add support for repeating keys to the Wayland input backend.
Unfortunately the repeat delay/interval is hardcoded into the Clutter
backend, as Wayland doesn't yet tell clients what the global values
should be.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
For Wayland, this is mostly the input protocol having changed, although
there's also the SHM pool API, the cursor API, as well as fullscreen and
ping.
Also port to the new (months-old) xkbcommon API, as used by Weston 0.95.
This involves having xkbcommon manage the state for us, where
appropriate. Fans of multi-layout keyboards (or just caps lock) will no
doubt appreciate these changes.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Looks like we need to include this directly, but also need to include
cogl/cogl.h to get COGL_HAS_EGL_SUPPORT, since cogl-egl.h doesn't
include cogl-defines.h first.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The X11-specific windowing checks were hidden behind an #ifdef, however
if the tests were run under Wayland, they would execute uncondionally
and cause assertion failures. Fix this by also hiding them behind a
check that the current backend is indeed X11.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
If a button press happen on stage and the pointer is moved outside
the stage while holding the mouse button, the motion and release
events are still delivered to actors. Do the same X11 soft grab
emulation for touch events.
https://bugzilla.gnome.org/show_bug.cgi?id=685589
On various systems, trying to release a mutex that hasn't been acquired
will result in a run-time error.
In order to avoid this, we trylock() the Big Clutter Lock™ and
immediately unlock() it, regardless of the result; if the lock was
already acquired, trylock() will immediately fail, and we can release
it; if the lock was not acquired, trylock() will succeed, and we can
release the lock immediately.
This is necessary to maintain binary compatibility and invariants for
Clutter applications doing:
clutter_init()
clutter_threads_enter()
...
clutter_main()
...
clutter_threads_leave()
instead of the correct:
clutter_init()
clutter_threads_enter()
...
clutter_threads_leave()
clutter_main()
clutter_threads_enter()
...
clutter_threads_leave()
With Clutter ≥ 1.12, the idiomatic form is:
clutter_init()
...
clutter_main()
given that the public Big Clutter Lock™ acquire/release API has been
deprecated, and nobody should take the lock outside of Clutter itself.
https://bugzilla.gnome.org/show_bug.cgi?id=679439
-Make things a bit cleaner by generating clutter.def in the intermediate
build folder
-Fix the include paths as config.h is now in clutter/
-Make things a little bit more consistent between vs9 and vs10 in terms of
the "install" stage
When the last touch has been released the stage on the
corresponding master device (eg. the virtual core pointer) is set
to NULL and no mouse events can be delivered until an ENTER event
has occurred and the stage pointer restored.
This is due to the fact that the master devices can send both
touch events and mouse events, forwarding events coming from the
attached slave devices.
To restore delivery of mouse events we need to ensure that the
stage is set on each ButtonPress, ButtonRelease and Motion event
coming from master devices.
https://bugzilla.gnome.org/show_bug.cgi?id=684509
When using the new ActorAlign flags we must get the real alignment for
the horizontal axis, as clutter_actor_allocate() will compute the
effective alignment by itself; if we use the effective alignment then
ClutterActor.allocate() will swap it, and undo our work.
When using the old BinAlignment flags we should reverse the alignment
depending on whether the text direction of the child is RTL or LTR.
See bug: https://bugzilla.gnome.org/show_bug.cgi?id=684214
It should be possible to destroy the actor currently being dragged from
within the ::drag-end signal. In order to do this, we need to keep a
reference on the action for the duration of the emit_drag_end() function
as well as resetting the action's state inside the dispose()
implementation, to avoid trying to access cleared data.
https://bugzilla.gnome.org/show_bug.cgi?id=681814
