This changes the Windows text handling so that keyboard events are sent to the framework first for handling, and then passed to the text input plugin, so that the framework has a chance to handle keys before they get given to the text field.
This is complicated by the async nature of the interaction with the framework, since Windows wants a synchronous response. So, in this change, I always tell Windows that the event was handled, and if the framework (eventually) responds that it wasn't, then I synthesize a new event and send it with SendEvent.
I also added support for detecting "extended" keys, since that was missing, and converted the OnKey handlers in the API to return a bool to indicate whether or not they have handled the event.
During multi-step text input composing, such as with Chinese, Japanese,
and Korean text input, the framework sends embedders cursor rect updates
in the form of two messages:
* TextInput.setMarkedTextRect: notifies the embedder the size and
position of the composing text rect (or cursor when not composing) in
local coordinates.
* TextInput.setEditableSizeAndTransform: notifies the embedder of the
size of the EditableText and 4x4 transform matrix from local to
PipelineOwner.rootNode coordinates.
On receipt of either message, we cache a local copy on the
TextInputPlugin and notify the Win32FlutterWindow of the updated cursor
rect. In a followup patch, we update Win32FlutterWindow to implement the
Win32 input manager (IMM) calls required to position the IME candidates
window while editing.
This is a partial revert of 7c19824c6d08bb8e3fc4217058178d42d451e26b
On some devices we still need to the original search paths approach
because dlopen with just the base file name doesn't work. We're
combining both approaches now, adding the base filename as the first
entry in the searchPaths.
When .so files are in the lib/ path in the APK, it can be dlopen-ed
directly using just the filename. We don't need to search for the file.
The interface has thus been changed to accept a single path instead of a
search directory.
Also instead of hardcoding the .so basename and assets directory, read
them from FlutterApplicationInfo instead.
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.
Started asserting that metal gpu contexts are shared, added ability
for IOSContexts to store their skia contexts so we can make the OpenGL
code work like the Metal code.
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.
