* partial implementation for emscripten
this pull request contain a partial but working implementation of emscripten backend
some implementations may be controversial.
here some implementation detail:
* cursor state:
* on grab: emscripten request pointer lock deferred and also set a callback when pointer lock change
the callback request pointer lock deferred.
* on hide: `emscripten_hide_mouse` exist but not `emscripten_show_mouse`
a pull request has been open on october 2016 but never been merged
so I copied the javascript function and put it in emscripten_asm_const function
* fullscreen: if fullscreen is requested then it request fullscreen deferred and set a callback on fullscreen change
the callback request fullscreen deferred
* run forever: this method use emscripten main loop to run an infinite loop
* keyboard callback doesn't consume the event. I think it is more apopriate as in desktop environment it is the same, is it ?
* emscripten dir is added in example and contains html pages
Some things that are not implemented:
* lots of events
* min and max dimension can be implemented with a callback that listen to size change and resize if dimension out of bound
* title may be implemented using javascript to change document.title
* Use std::os::raw in the emscripten bindings
* Fix emscripten code
* Update code
* Add CI
* Remove the emscripten-specific examples
* Add some information to the README
* Fix X11 screen resolution change using XrandR
The previous XF86 resolution switching was broken and everything
seems to have moved on to xrandr. Use that instead while cleaning
up the code a bit as well.
* Use XRandR for actual multiscreen support in X11
* Use actual monitor names in X11
* Get rid of ptr::read usage in X11
* Use a bog standard Vec instead of VecDeque
* Get rid of the XRandR mode switching stuff
Wayland has made the decision that apps shouldn't change screen
resolutions and just take the screens as they've been setup. In the
modern world where GPU scaling is cheap and LCD panels are scaling
anyway it makes no sense to make "physical" resolution changes when
software should be taking care of it. This massively simplifies the
code and makes it easier to extend to more niche setups like MST and
videowalls.
* Rename fullscreen options to match new semantics
* Implement XRandR 1.5 support
* Get rid of the FullScreen enum
Moving to just having two states None and Some(MonitorId) and then
being able to set full screen in the current monitor with something
like:
window.set_fullscreen(Some(window.current_monitor()));
* Implement Window::get_current_monitor()
Do it by iterating over the available monitors and finding which
has the biggest overlap with the window. For this MonitorId needs
a new get_position() that needs to be implemented for all platforms.
* Add unimplemented get_position() to all MonitorId
* Make get_current_monitor() platform specific
* Add unimplemented get_current_monitor() to all
* Implement proper primary monitor selection in X11
* Shut up some warnings
* Remove libxxf86vm package from travis
Since we're no longer using XF86 there's no need to keep the package
around for CI.
* Don't use new struct syntax
* Fix indentation
* Adjust Android/iOS fullscreen/maximized
On Android and iOS we can assume single screen apps that are already
fullscreen and maximized so there are a few methods that are implemented
by just returning a fixed value or not doing anything.
* Mark OSX/Win fullscreen/maximized unimplemented()!
These would be safe as no-ops but we should make it explicit so
there is more of an incentive to actually implement them.
* 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
* Rework MonitorId::get_native_identifier
* Try fix compilation
* Returns the monitor ID on wayland as well
* Try fix compilation
* Fix iOS compilation
Use the enum to make a single fullscreen API that's much more
consistent. Both set_fullscreen() and with_fullscreen() take the
same enum and support all the variations so you can build the window
however you want and switch between the modes at runtime.
There are two kinds of fullscreen. One where you take over the whole
output the other where you just set the window size to the screen
size and get rid of decorations. The first one already existed,
implement the second which is more common for normal desktop apps.
Use an enum to consolidate all the fullscreen states.
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.
X11 always return the geometry in pixel units. Since
window.get_inner_size returns the size in points in other window manager
implementations X11 should also return in points instead of pixels.
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
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`.
* Remove NSTitledWindowMask for windows with no decorations. This
makes sure that they do not have a title bar.
* Transparency is not be taken into account as we could have a window
with a titlebar or without that is transparent.
Making applications track modifier keys results in unnecessary work for
consumers, it's error prone, and it turns out to have unavoidable bugs.
For example, alt-tabbing with x11 results in the alt modifier state
getting stuck.
To resolve these problems, this patch adds a Mods value to the keyboard
input event.
Based on this patch: d287fa96e3
the NSApplication is in focus.
This NSEvent produces an undocumented NSEventType value `21` that has no
associated variant within the cocoa-rs crate's `NSEventType` enum, thus
causing a segfault when attemptingt to match on the value.
This commit adds a check for `21` to avoid the segfault.
This fixes#104.
Fix issue where key window would lose all mouse events once mouse left
that window.
Make sure that only window under mouse receives mouse scroll wheel
events.
invariants
This also removes the need for "box"ing the callback in favour of
storing a raw `*mut` pointer. We can do this by ensuring that we never
store the pointer for longer than the lifetime of the user callback,
which is the duration of a call to `poll_events` or `run_forever`.
Also removes old commented out event code from the window module.
This is a follow up to the new API introduced in #20.
This also fixes the issue where window resize events would not be
emitted until the end of the resize. This PR fixese #39 by ensuring that
the user callback given to either `EventsLoop::poll_events` or
`EventsLoop::run_forever` can be called by each window delegate's resize
callback directly.
This tracks resizes separately, and synthesizes them for the event iterators as needed, so that OS X apps don't generate a whole set of resize events after each resize.
These events are batched, and delievered en masse at the end of the resize. This isn't a great developer experience (and it should probably be called out in the docs), but it makes it possible for winit client applications to detect and respond to resizes without special-casing Mac OS targets.
See #39. This is only a partial fix, and does not provide on-the-fly resize events.
This fixes propagation of Event::Awakend from wakeup_event_loop() when
using poll_event() on macOS.
Currently wait_event() translates all unknown events into
Event::Awakened so doesn't need the explicit translation.
