* Web
* macos
* Linux
* Easier web impl
* doc and format
* Better linux impl
* Format
* Better impl mac
* Format
* Windows
* Format
* Apply suggestions from code review
Co-authored-by: Greg Spencer <gspencergoog@users.noreply.github.com>
Co-authored-by: Greg Spencer <gspencergoog@users.noreply.github.com>
TextInputType.none makes it possible to disable the virtual keyboard
for certain TextFields, and lays the foundations for custom in-app
virtual keyboards (flutter/flutter#76072).
Ref: flutter/flutter#83567
Used the the `misspell` tool available at
https://github.com/client9/misspell, then applied hand-corrections. It's
possible we could adopt this as a presubmit, but there are still enough
false positives that it may not be worth the effort.
While we no longer crash when the framebuffer destruction_callback is
null (patched in https://github.com/flutter/engine/pull/24845) we should
bet setting one, even if it's a no-op containing a comment pointing to
where cleanup is implemented.
Fixes the following compilation error:
../../flutter/shell/platform/linux/fl_key_event_plugin.cc:189:7:
error: format specifies type 'long' but the argument has type
'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]
On X11 scroll events are being directly sent to the FlView X window. This is
causing them to bypass the normal scroll handling and means this widget received
both smooth and non-smooth scroll events.
I haven't been able to find a solution to the root cause of the problem, so only
smooth scroll event are being processed. This could cause issues on older
versions of the X server that don't send smooth scroll events, but fixes the
problem for the common modern case.
This issue doesn't occur in Wayland.
Fixes an indexing error in the linux key handling code.
I also found another error when checking to see if an event is re-dispatched, and some off-by-one errors in the search. Not sure what I was smoking that day, but hopefully these are all the issues.
This PR makes the Linux key handling code a little more lenient when it comes to the order in which it receives responses to key events from the framework. I had assumed that there wasn't a case where responses could get out of order, but it seems that it is possible, given that you can mash on the keyboard and eventually get one out of order.
This changes the code so that instead of just looking at the first entry in the pending event deque, it searches the deque starting at the beginning to find the event, and remove it.
