-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Touch support #57
Touch support #57
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is awesome! Thank you 🎉
I think we should wait until rust-windowing/winit#1082 is correctly implemented for iOS before merging. Currently, the PR is rolling back winit
to use the old RedrawRequested
API, which causes smooth resizes to be somewhat broken on desktop. I can try to get the web backend version of winit
there, but some help for iOS would be appreciated as I do not own an iOS device.
Could the positions be removed from Touch::Ended
and Touch::Cancelled
or can they be different from the last Touch::Moved
? I am also guessing we will need to account for multiple fingers at some point, so we may need more data to identify the events in the future.
wgpu/Cargo.toml
Outdated
@@ -15,5 +15,5 @@ wgpu_glyph = { version = "0.5", git = "https://github.com/hecrj/wgpu_glyph", bra | |||
raw-window-handle = "0.3" | |||
image = "0.22" | |||
glam = "0.8" | |||
font-kit = "0.4" | |||
font-kit = { git = "https://github.com/simlay/font-kit", branch = "add-ios-support" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is waiting for servo/font-kit#110 to get merged.
winit/src/application.rs
Outdated
|
||
// TODO: Handle animations! | ||
// Maybe we can use `ControlFlow::WaitUntil` for this. | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should be able to revert this once rust-windowing/winit#1082 is resolved.
1b484c3
to
4fba2f2
Compare
87b89f9
to
c2f9fb9
Compare
It looks like a lot of progress has been made since last year, how's this looking? |
13ff494
to
971dbde
Compare
@hecrj Well, I squashed the commits (it was a pretty brutal rebase).
I haven't been keeping up with all the widgets this project has added since I opened the PR so I'm not sure which widgets don't have touch support. |
971dbde
to
58ec5dc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Just a couple of details.
I do not think there have been any new interactive widgets. However, there is #36 which will most likely need to be adapted to also work with touch events.
bcdc9e1
to
eb0bbfb
Compare
@hecrj This good to merge? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
About merging... I've given it some more thought, and I don't believe I can commit to maintaining this myself on master
for the time being. Targetting the desktop and the web is already tricky enough and bringing touch events into the equation seems to complicate event processing a bit.
I could create an (even more) experimental mobile
branch and we could merge this there (and maybe mention it in the README
). This should allow us to explore completely different strategies for mobile (like IMEs) and I'd gladly accept PRs of anyone who wants to keep it up-to-date with master
. Would you be okay with this?
Of course, there is also the possibility of you maintaining your own fork, but that may be less welcoming for new contributors!
In any case, I made some changes and turned the Touch
type into a struct to unify the position and add finger data. I think it's an improvement. Let me know what you think!
Touch is not exclusively mobile, it's definitely a thing on desktop too! (oh and IMEs are too!) For my project (desktop dock), I can get away with pointer emulation — actually I've implemented a very particular behavior where it's clicking on release, so I can glide up from the bottom of the screen to pick an item. The usual proper touch support would be worse for this unusual application :) but customization of input handling is a separate issue, for most apps we need something like this PR. |
@myfreeweb You are completely right. Looking back at this now, I am not sure I was being reasonable. I do not see a lot of complexity in these changes. Maybe the "mobile" part of the title scared me a bit at the time 😅 Thanks for bringing this back to my attention! I will work on getting this merged soon. |
Does that PR also add IOS support for iced ? |
I think I've brought this up to speed. I have ended up turning the Proper support for the latest widgets is missing, but I imagine we can add that in further PRs. For instance, #650 seems to be adding touch support to the I also haven't tested the changes, as I don't have a touch device at hand. I'd appreciate it if someone could try them out and report back. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can let this ship sail! We can iron out any potential issues later.
Thank you everyone! 🎉
Great news! |
I've got mixed feelings about some of this - like that each touch enum has a position in it. I could have done it more similar to how the mouse events work.
I've tested the todo and tour examples on my iPhone 8 with iOS 13.2.2, the things that don't work are:
Here's what the tour example looks like (up to just before the rust image):