Conversation
This comment was marked as outdated.
This comment was marked as outdated.
7df1935 to
b0318f4
Compare
1c90706 to
c6aaaf0
Compare
chrisduerr
left a comment
There was a problem hiding this comment.
Always impressive to me how much winit manages to change without improving anything. The API seems to have gotten worse somehow.
alacritty/src/display/window.rs
Outdated
| }, | ||
| #[cfg(all(feature = "wayland", not(any(target_os = "macos", windows))))] | ||
| RawDisplayHandle::Wayland(_) => { | ||
| Self::get_wayland_window(identity, window_config, activation_token) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
The attributes is the problem, we need platform specific attributes. Probably should rename all the function to get_platfrom_window_attributes and such.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Sounds like yet another breaking change coming up? 🥲
20f6734 to
145d8cb
Compare
145d8cb to
d00ebf6
Compare
d00ebf6 to
516e785
Compare
516e785 to
b9bb2b6
Compare
alacritty/src/display/window.rs
Outdated
| }, | ||
| #[cfg(all(feature = "wayland", not(any(target_os = "macos", windows))))] | ||
| RawDisplayHandle::Wayland(_) => { | ||
| Self::get_wayland_window(identity, window_config, activation_token) |
There was a problem hiding this comment.
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)] |
There was a problem hiding this comment.
What's deprecated here? NamedKey::Hyper? If so, what's the alternative going to be?
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
there's no keyboard with them
You're not using a Space-cadet keyboard?
b9bb2b6 to
76d43e4
Compare
c1cb283 to
b79d663
Compare
chrisduerr
left a comment
There was a problem hiding this comment.
Seems fine now, I'd just like to wait for a stable release.
|
|
||
| ### Added | ||
|
|
||
| - Tablet input support. |
There was a problem hiding this comment.
| - Tablet input support. | |
| - Tablet input support |
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). |
|
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. |
b79d663 to
3473acb
Compare
No description provided.