packages
packages copied to clipboard
flutter
[url_launcher]: Bump androidx.annotation:annotation from 1.8.2 to 1.9.0 in /packages/url_launcher/url_launcher_android/android
Bumps androidx.annotation:annotation from 1.8.2 to 1.9.0.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "Published by a pub.dev verified publisher"){kind=small}
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact "@test-exemption-reviewer" in the #hackers channel in Chat (don't just cc them here, they won't see it! Use Discord!).
If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?
Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.
![flutter-dashboard[bot] avatar](https://avatars.githubusercontent.com/in/64368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Thanks for working on this! I did a quick first review, the main issues seem to be moving this logic into it's own class and using GObject style instead of C++ style.
Thank you for the feedback! I’ll try to allocate some time for the restructuring next week.
I’ve been testing the code since the PR was opened, and I found an issue with the current implementation on Ubuntu 24.04. When using a three-finger gesture to switch between applications, the touch_event_cb's GDK_TOUCH_END part is not triggered when focus is lost. This results in various unexpected behaviors because the pointers are not removed. Do you have a suggestion for which signal handler could be used to handle this? Thanks in advance!
Based on the behaviour of the other GTK input events I think you just have to handle the missing events and synthesize any that are missing. This is because Flutter expects a perfect input stream and GTK doesn't seem to guarantee this. I expect the event was intercepted by the shell or another layer in GTK and will not be reported to the application.
If you do think it's a mistake in GTK though please make a test case and report at https://gitlab.gnome.org/GNOME/gtk/ - that should clarify if we need to handle this ourselves.
@RBT22 Are you planning on resuming the work for this soon ?
The lack of multi-touch handling on linux is currently a blocking issue here...
Sorry for the inconvenience, everyone. Something urgent has come up, and I likely won’t be able to finish this in the next 2-3 weeks.
@chrisDexfo I'm still having higher priority tasks at the moment. It will likely take about two more weeks to resolve. I'll be sure to get back to this project as soon as possible after that. Thanks for your understanding!
This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold.
I’ve done some refactoring. @robert-ancell, could you please take a look?
The issue I mentioned earlier with the missing GDK_TOUCH_END events still persists. We use our app with GNOME gestures disabled, so I didn’t explore that further. I’m not entirely sure where the event synthesis should occur. What I did find is that the leave_notify_event_cb is being triggered in those cases, but with a time value of zero.
I wonder how you see the relationship between the touch manager and the pointer manager.
- I was guessing that you'd like touch manager manages touch screens, while the pointer manager manages mouse. (There will be some duplicate code but it might be acceptable, since handling multi-pointer is different from handling buttons.) However, in this case the touch manager should not need to handle buttons at all.
- Or you might want to create a unified handler that handles both multi-pointer and buttons. But then you'll want to remove the pointer manager, which this PR doesn't.
@dkwingsmt I see what you mean about the relationship between the touch manager and pointer manager. Maybe it’d make sense to move a simplified state to the fl_touch_manager from the engine to clean things up a bit?
As for a unified handler, I get the idea, but I’m not up for tackling that myself right now. :)
Yeah I wouldn't expect the unified one as well. So I'm practically saying that you should not need to handle buttons. :)
I moved and simplified the state to FtTouchManager. Also, I integrated the ID generation.