This removes the need for the EventsLoop::interrupt method by inroducing
a ControlFlow type. This new type is to be returned by the user's
callback and indicates whether the `EventsLoop` should continue waiting
for events or break from the loop.
Only the wayland, x11 and api_transition backends have been updated so
far, and only the wayland backend has actually been tested.
X11 and Wayland implementations are now half implemented, however both
still do not correctly break from the inner blocking event dispatch
functions when `wakeup` is called, which they should do.
This commit only updates the top-level API to get some early feedback.
None of the platform-specific code has been updated yet. I'm hoping to
get around to this over the next couple days however if someone more
familiar with the windows backend would like to do a PR against this
fork that would be a great help.
Closes#187.
If the interrupted flag were set going into poll_events, it would only
ever handle the first event in the queue. Now, the flag is reset at the
start so events are processed until the caller requests otherwise.
This is the same behavior as with WindowProxy::wakeup_event_loop in
previous versions.
Unfortunately, `EventsLoop::interrupt` is also the recommend way to exit
a `run_forever` loop from within the event handler callback. Pushing an
extra event on the queue in that case is simply wasteful. Changing this
would require a refactor taking one of two possible forms:
1. Add a method *in addition* to interrupt intended for waking up the
event loop
2. Add a return type to the event callback like
enum Continue { True, False }
which would be used in lieu of the atomic interrupt flag.
It was only processing a single event per call. The docs say
> Fetches all the events that are pending, calls the callback function
> for each of them, and returns.
which suggests that was incorrect.
All platforms should now receive events in the following order:
1. KeyboardInput(ElementState::Pressed, ..)
2. ReceivedCharacter
3. KeyboardInput(ElementState::Released, ..)
cc https://github.com/tomaka/glutin/issues/878
ICCCM 4.1.2.5 (https://tronche.com/gui/x/icccm/sec-4.html#WM_CLASS)
states that:
> This property must be present when the window leaves the Withdrawn
> state and may be changed only while the window is in the Withdrawn
> state.
Previously, we would first map the window, and then set these
properties, causing sadness for window managers (#167,
tomaka/glutin#879). This patch changes that by setting the class and
name attributes immediately after the window is created, and before it
is mapped.
Fixes#167.
This expands input events to represent sub-pixel mouse positions, devices responsible for generating events, and raw
device-oriented events. The X11 back end is refactored to make full use of the new expressiveness. Other backends have
had new functionality minimally stubbed out, save for the macos backend which already supports sub-pixel mouse
positions.
Previously, if a `Window` was `Drop`ped while open, the window would
remain open until the user pressed the x button. This fixes the
behaviour so that the window is closed when dropped if it has not
already been closed.
This can happen when window is destroyed/created during a call to user
callback as this causes WindowDelegate method to be called.
Instead if the user callback is `None` store the event in
`pending_events`.
