wait_event used to call nextEventMatchingMask twice. Once with untilDate:distantFuture,
and dequeue:NO to wait until the next event but witout consuming it, and again with
untilDate:distantPast and dequeue:YES to retrieve the event (via poll_events).
For some reason, with osx 10.11, calling nextEventMatchingMask with dequeue:NO never
returns if the user scrolls, freezing the app.
So we now call nextEventMatchingMask only once, with dequeue:YES.
Integrate with wayland-window crate to draw decorations
allowing resize & move of the window.
Leaving the wayland backend as disabled until full usability
is ensured.
fixes#314 for me.
I've "tested" change by running examples (which prior to change simply
crashed), but since I did not run those examples successfuly ever before,
I don't know whether they worked as intended.
XInput2 has a concept of master and slave devices,
where a slave device is the actual physical device,
attached to a master device representing the cursor or keyboard
focus.
See http://who-t.blogspot.co.uk/2009/05/xi2-recipes-part-1.html
Mouse events were being received from both the master and slave
devices, but we are only interested in events from the master device.
Fixes#533
* Fix an issue where PollEventsIterator::next() would fail to return
keyboard input and mouse events immediately but instead only
return them on the next call to next()
* Inline process_generic_event() and queue_event()
Scroll deltas are calculated in X11 by comparing the current and
previous absolute values for the scroll axis when a scroll motion
event is received. If the user scrolls whilst the cursor is outside
of the window then an incorrect delta is reported when the cursor
re-enters the window.
Fix this by resetting the last-seen axis values whenever the cursor
re-enters the window.
* For the moment we're still using plain core X11 events
for handling keyboard activity, so remove the XInput2 code for that
* Small refactoring of X11 input handling and documentation fixes
