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
* make windows without decorations resizable and movable in macos
fixes#368
The subclassing logic was copied from servo's fork of glutin:
63026a0f4c/src/api/cocoa/mod.rs (L418)
* remove `isMovableByWindowBackground` and `mouseDownCanMoveWindow`
* revert example changes
* remove resizable mask from decoration: false
* avoid duplicate class declarations
* update changelog
* fix changelog
* changelog whitespace
* 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.
* macOS: Allow hiding the title from the titlebar
* macOS: Allow making the titlebar transparent
* macOS: Give control over content view size
Allows setting `NSFullSizeContentViewWindowMask` with WindowBuilder.
* macOS: add `.with_titlebar_hidden` to WindowBuilderExt
* macOS: adds `titlebar_buttons_hidden` platform specific attribute
Due to the recent changes in the Rust compiler, unconstrained type
variables are now deduced to `!` instead of `()`. There are some
occurrences where `msg_send!` is used without constraining its return
type (relying on the assumption that they would be deduced to be `()`).
As a result, the macOS port of winit stopped working.
This PR fixes this issue (#426) by adding explicit return types to
such uses of `msg_send!`.
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.
* macOS: Move the window if there is no title bar
On macOS by default windows can only be moved by clicking and
dragging on the titlebar, if we spawn a window without one we
need to set the `movableByWindowBackground` property.
Partial fix for #368
* macOS: Make moveByWindowBackground optional
Implements setting the property via WindowBuilderExt:
WindowBuilder::new()
.with_decorations(false)
.with_movable_by_window_background(true)
* Update CHANGELOG
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.
