Previously, the function would actually set the outer size of the window
instead of the inner size.
We fix this by first letting windows calculate the outer size based upon
the specified inner size.
From the "Smooth Scrolling" section of [XI2Proto.txt][1]:
> One unit of scrolling in either direction is considered to be equivalent to
> one button event, e.g. for a unit size of 1.0, -2.0 on an valuator type
> Vertical sends two button press/release events for button 4. Likewise, a
> button press event for button 7 generates an event on the Horizontal
> valuator with a value of +1.0. The server may accumulate deltas of less than
> one unit of scrolling.
From [What's new in XI 2.1 - smooth scrolling][2]:
> The increment defines what delta the driver considers to be one scroll
> event. For an increment of +5, each delta of 5 should be regarded as one
> scroll unit down. For an increment of -3, each delta of 3 should be regarded
> as one scroll unit up (i.e. inverted).
[1]: http://www.x.org/releases/X11R7.7/doc/inputproto/XI2proto.txt
[2]: http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-smooth-scrolling.html
This fixes scrolling with my Microsoft mouse in X11 on Debian 8.1.
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.
