* Try XOpenIM with different locale modifiers
Implements the solution suggested in
https://github.com/tomaka/winit/issues/277#issuecomment-337751136.
* Use empty XSetLocaleModifiers beforehand
Also, for modifiers, convert from length-based UTF-8 strings to
null-terminated bytestrings.
* Add CHANGELOG entry and comments
Fixes#79#414
This changes the implementation of Drop for Window to send a WM_DELETE_WINDOW ClientMessage,
offloading all the cleanup and window destruction to the event loop. Unsurprisingly, this
entails that the event loop now handles WM_DELETE_WINDOW using the behavior that was
previously contained in Window's Drop implementation, along with destroying the Window.
Not only does this mean that dropped windows are closed, but also that clicking the × button
on the window actually closes it now.
The previous implemention of Drop was also broken, as the event loop would be (seemingly
permenanently) frozen after its invocation. That was caused specifically by the mutex
locking, and is no longer an issue now that the locking is done in the event loop.
While I don't have full confidence that it makes sense for the Drop implementation to behave
this way, this is nonetheless a significant improvement. The previous behavior led to
inconsistent state, panics, and event loop breakage, along with not actually destroying the
window.
This additionally makes the assumption that users don't need Focused or CursorLeft events
for the destroyed window, as Closed is adequate to indicate unfocus, and users may not
expect to receive events for closed/dropped windows. In my testing, those specific events
were sent immediately after the window was destroyed, though this sort of behavior could be
WM-specific. I've opted to explicitly suppress those events in the case of the window no
longer existing.
The `CursorMoved` events that are used to send position updates alongside `Focused` and
`CursorEntered` events were using incorrect values for the window ID. This is a direct
result of the X11 backend being hard to understand, as those values came from variables in
the top-level scope of the function, which one would assume to be valid throughout the
entirety of their scope. In reality, their validity is dependent on the event belonging to
the `XEvent` union, so very surprising things can happen if those variables are read in the
case of XInput2/XKB/etc. events. To prevent future accidents, the aforementioned variables
have been removed, and are now defined per-event instead.
Additionally, the `CursorMoved` event sent alongside `Focused` now uses the correct device
ID; it previously used the ID of a master keyboard, but now uses the ID of the pointer
paired to that keyboard. Note that for those using multi-pointer X, the correctness of this
ID is dependent on the correctness of the window manager's focus model.
Previously, the maximization hints were being sent as two separate client messages: one for
horizontal, and one for vertical. That resulted in the window only being maximized
horizontally (at least with my WM). The corrected client message sets both of these hints at
once.
In the process of implementing that, the relevant components were refactored to use the util
module, as we gradually move towards a hopeful future of a more readable X11 backend.
* Update mouse pos after cursor enter event
* Update mouse position on windows focus
* Send device_id
* Update other device id
* Fix windows import
* Remove deque for vec
* Just send event
* Use correct push_back method
* Push correct event
* Explicit mouse-related DeviceEvents
This makes the API more intuitive for common use-cases and allows us
to better propagate platform knowledge of motion semantics.
* Improve event naming consistency
* Clarify axis event forwards-compatibility
* Rename WindowEvent::MouseMoved/Entered/Left to CursorMoved/...
This emphasizes the difference between motion of the host GUI cursor,
as used for clicking on things, and raw mouse(-like) input data, as
used for first-person controls.
* Add support for windows and OSX, fix merging
* Fix warnings and errors on Linux
* Remove unnecessary breaking changes
* Add MouseWheel events to windows and OSX
* Fix bad push call.
* Fix docs, naming, and x11 events
* Remove mutability warning
* Add changelog entry
* Don't use UNIX_BACKEND in Window2::new
* Move get_available_monitors and get_primary_monitor to EventsLoop
* Remove UNIX_BACKEND
* Restore choosing the Linux backend
* Return a XNotSupported for new_x11()
* Fix fullscreen example
When X's evdev input module is configured to emulate scroll events (as
used with e.g. trackpoints), it generates non-emulated scroll button
presses and does not generate motion events. This is contrary to the
behavior of all other hardware I've tested, and contrary to the
behavior of libinput, but nonetheless should be supported.
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.
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
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.
