Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Winit version 0.29.11 #3492

Merged
merged 33 commits into from
Feb 26, 2024
Merged

Winit version 0.29.11 #3492

merged 33 commits into from
Feb 26, 2024

Conversation

kchibisov
Copy link
Member

@kchibisov kchibisov commented Feb 13, 2024

--

#3491

@daxpedda
Copy link
Member

Please include #3371 as well.
Let me know if you want me to push it or make a PR against your branch.

daxpedda and others added 22 commits February 18, 2024 01:46
`window.set_ime_cursor_area` requires a position from the top left
corner according to the documentation. However, the NSRect's origin is
from bottom left. The y coordinate should correctly calculated for the
NSRect.
This let statement swapped the two names, resulting in incorrect
behavior since commit d7ec899. That commit did not actually introduce
the swap, but the previous code swapped it again before setting the
WM_CLASS property, so no issue was ever observed.

It also brings the documentation in line with the implementation since the
parent commit, and with the ICCCM standard, which states the following
about the WM_CLASS property [1]:

  The two strings, respectively, are:
  * A string that names the particular instance of the application [...]
  * A string that names the general class of applications [...]

[1] https://www.x.org/releases/current/doc/xorg-docs/icccm/icccm.html#WM_CLASS_Property
Change in state requires a redraw, however drawing when getting
`Occluded` with vsync will block indefinitely, thus the event in
it's current state is rather useless.

To solve this issue winit needs a way to determine whether the user
paused/continued their render loop, so it can commit on their behalf.

This commit also forces redraw when getting configure.

Links: #3442
This also fixes the deadlock when such reload may happen.

Fixes: #3383
Signed-off-by: John Nunley <dev@notgull.net>
Signed-off-by: Kirill Chibisov <contact@kchibisov.com>
Given that we merge all the seats, we should consider that window
is not focused once all seats wl_keyboards are no longer present.

We use seats instead of keyboards to track focus to protect against
wl_keyboard::leave not being delivered when removing the seat
(usually it's not the case though).

Fixes: #3376
The size is only applied on the next `wl_surface::commit` thus we
must trigger the redraw.
This fixes an issue when setting the position of the window on a new
monitor and immediately maximizing it

```rs
window.set_outer_position::<PhysicalPosition<u32>>((2000, 200).into());
window.set_maximized(true);
```

Due to the nature of the event loop, the requested position and
maximization state will apply correctly but due to the fact that the new
position is a different monitor, a `ScaleFactorChanged` is emitted
afterwards to the evenloop and a new size is set while the window is
still maximized which results in a window that has `WS_MAXIMZE` window
style but doesn't cover the whole monitor.
This also fixes `logical_key` and `text` not reported in `KeyEvent`.
We could fail to setup property watcher and fail to start, thus
don't require XSETTINGS to work.

Fixes: df8805c (On X11, reload DPI on _XSETTINGS_SETTINGS)
Remove the redundant `Rc` to access the window target.
Make code more clear wrt explicit returns during event handling,
which may lead to skipped IME event handling.
Implement the following methods on the `Window`:
  - `Window::set_cursor_grab`.
  - `Window::set_cursor_visible`.
  - `Window::drag_window`.
  - `Window::drag_resize_window`.
  - `Window::set_transparent`.
  - `Window::set_visible`.
  - `Window::is_visible`.
  - `Window::set_resizable`.
  - `Window::is_resizable`.
  - `Window::set_maximized`.
  - `Window::is_maximized`.
  - `Window::set_decorations`.
  - `Window::is_decorated`.
  - `Window::set_window_level`.

To make locked pointer useful, the `DeviceEvent::MouseMotion`
event was also implemented.
In general, we may want to use xinput v2 for keyboard input in such
cases, so we have compose going, but for now just don't crash if
there's no XIM.
madsmtm and others added 3 commits February 18, 2024 02:04
Co-authored-by: Kirill Chibisov <contact@kchibisov.com>
While there's a separate event to deliver modifiers for keyboard,
unfortunately, it's not even remotely reflects the modifiers state.

Thus use events along side regular modifier updates to correctly
detect the state. Also, apply the modifiers from the regular
key event by converting their state to xkb modifiers state.

Links: alacritty/alacritty#7549
Closes: #3388
@kchibisov kchibisov marked this pull request as ready for review February 17, 2024 22:06
@kchibisov
Copy link
Member Author

Please include #3371 as well.

Done.

@kchibisov kchibisov marked this pull request as draft February 21, 2024 01:49
Given that `ModifiersChanged` is a window event, it means that clients
may track it for each window individually, thus not sending it between
focus changes may result in modifiers getting desynced on the consumer
side.
@kchibisov kchibisov marked this pull request as ready for review February 22, 2024 04:42
@kchibisov kchibisov marked this pull request as draft February 22, 2024 05:35
@kchibisov kchibisov marked this pull request as ready for review February 26, 2024 09:06
@kchibisov kchibisov merged commit 8b6c8ef into v0.29.x Feb 26, 2024
50 checks passed
@kchibisov kchibisov deleted the kchibisov/rel-02911 branch February 26, 2024 09:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.