Commit graph

64 commits

Author SHA1 Message Date
Joe Wilm 4ec5078bdb Fix poll_events on x11 not draining completely
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.
2017-05-11 23:00:22 -07:00
Joe Wilm 46057d7122 Remove unnecessary locking
For X11 interrupt, we can just use the root window which doesn't require
taking a lock to find.
2017-05-09 21:30:31 -07:00
Joe Wilm f3db0ba641 Fix x11 interrupt to actually wake event loop
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.
2017-05-09 09:51:00 -07:00
Joe Wilm 8288d419fd Remove unnecessary mut 2017-05-09 09:50:16 -07:00
Joe Wilm c92ac695af Fix x11 poll_events to drain queue
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.
2017-05-09 09:20:35 -07:00
Joe Wilm 0b75a6b60c Make keyboard input event order consistent
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
2017-05-07 21:16:48 -07:00
tomaka 15aafc2908 Merge pull request #164 from Ralith/rich-input
Richer input events
2017-05-07 08:35:03 +02:00
Jon Gjengset 4087627b12
Set WM_CLASS and WM_NAME before mapping window
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.
2017-05-04 17:37:24 -04:00
Benjamin Saunders 22bc119cd7 Richer input events
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.
2017-04-23 01:08:15 -07:00
tomaka 2e82cac69a Merge pull request #154 from vberger/wayland_new_api
Port wayland to the new API
2017-03-11 09:04:09 +01:00
Gabriel Martinez 0b530b026d Support disabling window decorations in X11
This uses the incredibly old and ugly _MOTIF_WM_HINTS property:
http://stackoverflow.com/questions/5134297/xlib-how-does-this-removing-window-decoration-work

Using _NET_WM_WINDOW_TYPE from the Extended Window Manager Hints spec
(https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html)
would be preferred, but it requires knowing up front what the user
intends their window to be. _MOTIF_WM_HINTS should work for now.
2017-03-05 09:42:24 -08:00
Victor Berger 9aaa788434 linux: Remove dead code from wayland & fix some trivial warnings. 2017-03-04 11:26:12 +01:00
Victor Berger 624a422f20 linux: move api transition boilerplate to x11/wayland submodules 2017-03-04 09:09:09 +01:00
Victor Berger 4acf437221 Move api module into platform::linux 2017-03-04 09:09:09 +01:00