* x11: Windows are Sync again
Fixes#472
* Add test ensuring that Window is Sync
Window must be Sync for Vulkano's Arc<FramebufferAbstract> to be usable.
* Add get_inner_position for windows, prototypes for other platforms
* Fix linux builds
* Implement get_inner_position for osx
* Add get_inner_pos implementations for other platforms
* Fixed get_inner_position on macOS
* Corrected set_position on macOS
* Added CHANGELOG entry
Fixes#195Fixes#277Fixes#455
* Read `XMODIFIERS` explicitly/directly instead of calling `XSetLocaleModifiers` with an
empty string. This is useful for debugging purposes, and more clear to read and handle.
* Fallback to local input method if the one specified in `XMODIFIERS` is later closed on the
server end (i.e. if ibus/fcitx is terminated). Previously, that would cause the event loop
to freeze and usually also segfault.
* If using the fallback input method, respond to the `XMODIFIERS` input method later
becoming available. This means that the input method restarting is handled, and that even if
the program was started while ibus/fcitx/etc. was unavailable, it will start using it as
soon as it becomes available.
* Only one input method is opened for the whole event loop, with each window having its own
input context.
* IME works completely out of the box now, no longer requiring application developers to
call `setlocale` or `XSetLocaleModifiers`.
* Detailed error messages are provided if no input method could be opened. However, no
information is provided to the user if their intended `XMODIFIERS` input method failed to
open but the fallbacks (which will ostensibly always succeed) succeeded; in my opinion, this
is something that is best filled by adding a logging feature to winit.
XIM isn't thread-safe at all. Any call made to it from another thread will result in the
event loop freezing (this is why the old implementation of Drop for Window had that
problem).
XIM is now confined to one thread, and the existing API is maintained using channels. In
testing this with Alacritty, I initially thought the occasional slight lag on updating the
spot location was due to this change, but it's present without it as well.
* 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
* Add min/max size setting for win32 and wayland backends
* Implement dynamic min/max size on macos
* Add min/max size setting for x11
* Add empty functions for remaining platforms
* Improved min/max size setting for x11
* Added CHANGELOG entry for new min/max methods
* Added documentation for new min/max methods
* On win32, bound window size to min/max dimensions on window creation
* On win32, force re-check of window size when changing min/max dimensions
* Fix freeze when setting min and max size
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 fix for returning accurate window position lead to a regression
computing inner size in pixels. This commit resolves that by getting
inner size from the window ID winit caches and still resolving position
by climbing the window hierarchy.
Resolves#398
* x11: Support XRandR versions older than 1.5
Fixes#392
Previously, initializing the member `xrandr` of `XConnection` resulted
in a panic when symbols from XRandR version 1.5 were missing. There was
already code to handle older versions of XRandR but it was never
executed because of the panic.
The member `XConnection.xrandr` now contains only functions that can
safely be used with older versions. Additionally, this commit adds a new
member to `XConnection` of type `Option<ffi::XRandr>` that only contains
a value if version 1.5 functionality is present.
* x11: Document the xrandr* members of XConnection
Some window managers like i3wm will actually nest application windows
(like those opened by winit) within other windows to, for example, add
decorations. Initially when debugging this method on i3, the x and y
positions were always returned as "2".
The solution that other xlib abstractions use is to climb up the window
hierarchy until just below the root window, and that window must be used
to determine the appropriate position.
This patch doesn't take into account borders or the window's offset
within its parent, but it's much more usable than the original
implementation on certain WMs.
This was previously hardcoded to 1.0. The values for physical size in
millimeters and pixel counts on each axis are used to compute the dpi
per monitor.
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.
This has been stubbed on all platforms other than X11. The X11 implementation has also been
revised to toggle correctly, as it was previously only able to remove decorations.
Fixes#256
`get_xlib_window` and `get_xlib_screen_id` previously returned `Option<*mut c_void>` by
casting integer IDs into pointers, which while producing no functionality issues, is
semantically incorrect and rather surprising. Worse still, the docs for `get_xlib_window`
stated that it was in fact a valid pointer.
Additionally, now all `unix::WindowExt` methods return `std::os::raw` types rather than
`libc` types; note that the two versions of `c_void` are not interchangeable in the eyes of
the compiler, so those wanting the `libc` type will need to explicitly cast.
This is a breaking change, and will require some trivial changes to glutin.
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.
Fixes#282
Some tiling window managers (i3, dwm, etc.) determine how a window should behave based on
its name. If the name is set after mapping, then window managers will check the name before
we set it, followed by them detecting it as a change when the name is actually set. That
results in the window briefly behaving in an unexpected way, followed by a rapid switch to
the expected behavior.
In accordance to section 4.1.2 of ICCCM, the name, decorations, size hints, and window
deletion redirection have all been moved up to be set before mapping.
* 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
* wayland: upgrade wayland-window
This new version of wayland window considerably simplifies the
window handling for winit, meaning much of the previous juggling
is no longer needed, and the windows will appear even if nothing is
drawn.
* wayland: cleanup unused stuff
* Fix no primary monitor panic in XWayland
In this case try to use the first existing monitor instead of panicking.
Fixes#317
* Shift no monitor panic to x11::get_primary_monitor
* Update changelog with xll get_primary_monitor fallback
* Implement public API for high-DPI #105
* Recover get_inner_size_points and get_inner_size_pixels and change their implementation assuming get_inner_size() returns size in pixels
* Update changelog for high-DPI changes
This should trigger the compositor's mechanism for sending a
configure event, which should most of the time be processed
before any winit user actually tries to draw.
* Add an i386 target to travis
* Fix X11 on 32bit architectures
One would hope 32bit X11 was dead by now but apparently not :). Fix
the window hint setting code to not assume window IDs are 64bit as
apparently they are not in 32bit arches.
* wayland: don't create a second event_queue
As each EventsLoop has its own context, this is no longer necessary.
* wayland: buffer events rather than direct dispatch
Changes the behavior of the event loop to first internally
buffer the events generated by the wayland handlers, and then
dispatch them to the client's closure.
- It simplifies the event loop logic
- It makes it possible for the user to call window methods such as
`set_title()` or `set_inner_size()` without causing a deadlock
* wayland: add is_ready() & fix protocol errors
Adds a `is_ready()` method to the windows to advertize
when it is legal to start drawing, and fix a few wayland
protocol mishandling in the process.
* 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.
