Skip to content

Update to winit-0.31.0-beta.2#8750

Open
kchibisov wants to merge 2 commits intoalacritty:masterfrom
kchibisov:update-winit-031
Open

Update to winit-0.31.0-beta.2#8750
kchibisov wants to merge 2 commits intoalacritty:masterfrom
kchibisov:update-winit-031

Conversation

@kchibisov
Copy link
Member

@kchibisov kchibisov commented Nov 16, 2025

No description provided.

@ur4t

This comment was marked as outdated.

@kchibisov kchibisov force-pushed the update-winit-031 branch 4 times, most recently from 7df1935 to b0318f4 Compare November 22, 2025 14:07
@kchibisov kchibisov marked this pull request as ready for review November 22, 2025 14:09
@kchibisov kchibisov requested a review from chrisduerr November 22, 2025 14:09
@kchibisov kchibisov force-pushed the update-winit-031 branch 3 times, most recently from 1c90706 to c6aaaf0 Compare November 22, 2025 14:44
Copy link
Member

@chrisduerr chrisduerr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Always impressive to me how much winit manages to change without improving anything. The API seems to have gotten worse somehow.

},
#[cfg(all(feature = "wayland", not(any(target_os = "macos", windows))))]
RawDisplayHandle::Wayland(_) => {
Self::get_wayland_window(identity, window_config, activation_token)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it really necessary to create a window for each individual platform now? That seems like a horrible API. Wasn't the whole purpose of winit to abstract over this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The attributes is the problem, we need platform specific attributes. Probably should rename all the function to get_platfrom_window_attributes and such.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't the attributes be generic and work for all platforms though? The default is empty anyway, why does it matter if there's a with_activation_token function on X11 if you can just not call it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is actually how I personally want it to be, we just starting slow, since this mechanism should be in place anyway for out-of-tree backends, but over time, we'll make extensions like that into winit-core without platform restrictions, etc.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like yet another breaking change coming up? 🥲

@chrisduerr
Copy link
Member

@perfbot

@kchibisov kchibisov force-pushed the update-winit-031 branch 3 times, most recently from 20f6734 to 145d8cb Compare November 24, 2025 04:41
@perfbot
Copy link

perfbot commented Nov 24, 2025

results

@kchibisov
Copy link
Member Author

@perfbot

@perfbot
Copy link

perfbot commented Nov 24, 2025

results

},
#[cfg(all(feature = "wayland", not(any(target_os = "macos", windows))))]
RawDisplayHandle::Wayland(_) => {
Self::get_wayland_window(identity, window_config, activation_token)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't the attributes be generic and work for all platforms though? The default is empty anyway, why does it matter if there's a with_activation_token function on X11 if you can just not call it?

(NamedKey::Control, KeyLocation::Left) => "57442",
(NamedKey::Alt, KeyLocation::Left) => "57443",
(NamedKey::Meta, KeyLocation::Left) => "57444",
#[allow(deprecated)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's deprecated here? NamedKey::Hyper? If so, what's the alternative going to be?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We adopted keyboard types crate, which follows w3c standard when it comes to keys, etc for better inter-op with existing crates, and the thing is that Hyper and Super are deprecated in it, so this crate also follows deprecation here. While I'm not happy with it, it's what it is.

There's no alternative and it's not like they are going away. I'd maybe change it upstream to not make them deprecated, though, I have a feeling that I've already proposed something like that in the past...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the idea is that because it's not standard people should just use key codes? It seems pretty widely used, I'm surprised there wouldn't be something for it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think any of them are used, unless you explicitly add them. there's no keyboard with them, etc, and we don't use anything other than forwarding.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's no keyboard with them

You're not using a Space-cadet keyboard?

@kchibisov kchibisov requested a review from chrisduerr November 27, 2025 09:46
@kchibisov kchibisov force-pushed the update-winit-031 branch 3 times, most recently from c1cb283 to b79d663 Compare November 30, 2025 13:18
Copy link
Member

@chrisduerr chrisduerr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fine now, I'd just like to wait for a stable release.


### Added

- Tablet input support.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Tablet input support.
- Tablet input support

@kchibisov
Copy link
Member Author

, I'd just like to wait for a stable release.

I generally don't want to rebase it and it also brings crossfont up to date and allows to bump some other deps. I'd say that given I decide stable release pretty much, can ensure that it won't change much wrt things that are already in the PR.

@chrisduerr
Copy link
Member

I generally don't want to rebase it and it also brings crossfont up to date and allows to bump some other deps. I'd say that given I decide stable release pretty much, can ensure that it won't change much wrt things that are already in the PR.

By rebase it you mean for potential other changes in Alacritty? I think if winit is not changing and this is 'pretty much stable', then we might as well wait for a stable release because it sounds like it can't be far off. If it's not stable, then we shouldn't be merging it into master. So either way I'm not sure it makes sense to use pre-release versions (especially because we need to bump it again once it's stable).

@kchibisov
Copy link
Member Author

If we won't touch input handling for the time until it's stable, then I'm fine. I just don't want to rebase input handling over and over and thus retesting it.

@chrisduerr
Copy link
Member

chrisduerr commented Dec 1, 2025

If we won't touch input handling for the time until it's stable, then I'm fine. I just don't want to rebase input handling over and over and thus retesting it.

Yeah makes sense. Maybe we'll just hold this PR for now, but if we decide to work on anything else input/event-related we can just merge this first. I don't expect any external contributors to send a lot of big input-related patches.

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.

5 participants