* WIP
* Improvements for cursor control
* Enhance text selection and key event handling for Samsung keyboard compatibility
* Default to multine inputtype in android
* WIP Input configurations
* Enhance iOS text input handling
* Cleanup
* Comment out 'Next' variant across platforms for future implementation.
* Rename IME Config API to match web APIs
* Fix Android emoji deletion by implementing UTF-16 code unit index conversion
* Proper ASCII-only input and improve iOS keyboard handling
* Replace 'is_numeric_only' with 'input_mode'
* Prevent pasting invalid characters
* Cleanup
* Cleanup
* Hide clipboard actions on text change
* Cleanup
* Unify keyboard event types and fix iOS text input regressions
Unified TextInputEvent with new fields for better IME support across platforms:
- Added `composition` field for IME preview ranges (CJKinput)
- Added `full_state_sync` for complete buffer state (Android approach)
- Added `replace_range` for autocorrect/suggestion replacements (iOS approach)
All platforms: Standardized on CharOffset for character position handling
* Prevent text synchronization with the platform during active composition
* Add UITextInputCurrentInputModeDidChangeNotification support
* Add underline for active IME composition in TextInput
* Improve editor action handling for multiline inputs on Android
* Enhance IME composition tracking and clipboard action handling in TextInput
* Simplify IME state handling on Android
* Cleanup IME handling on iOS
* Cleanup
* Cleanup IME handling on iOS
* Improve docs/comments
* Improve docs/comments
* Add floating cursor support for keyboard trackpad in iOS
* Refine IME handling in TextInput to prevent iOS buffer loss during composition updates
* Move UITextInput protocol implementation into its own module
* Move MakepadInputConnection into its own file
* Cleanup
* Improve general IME handling in TextInput. Improve docs and comments
* Refactor text input configuration to separate soft keyboard settings for mobile platforms.
This bit of info was already tracked, but it wasn't exposed by the
`FingerMoveEvent` struct.
Doing so will allow widgets to differentiate between a gesture like
long-press then drag (for drag-n-drop) vs. just a regular drag
(for something like finger-based scrolling).
This is useful in TextInput, Dock, and any view that may respond
differently to a drag vs a "select then drag".
- MakepadTextInputView with marked text (composition) for CJK input
- UTF-16 ↔ char index conversion for emoji/Unicode handling
- TextRangeReplaceEvent for autocorrect/autocomplete
Cx API:
- Implement existing ShowClipboardActions
- Add HideClipboardActions
- Cross-platform API ready for iOS implementation
Android Implementation:
- Native ActionMode integration with floating toolbar (API 23+)
- JNI bindings for showing/hiding menu and handling clipboard actions
- Event system for Copy/Cut/Paste/Select All actions
- Smart menu state management based on selection and clipboard
TextInput Integration:
- Long press selects word and shows menu
- Double tap and long press selects word and shows menu
- Selection preservation when tapping selected text
* Fix button clicks during keyboard dismissal on mobile
When tapping a button while the keyboard is visible on iOS/Android, the keyboard dismisses and shifts the layout mid-press. This caused the event system to treat the finger as no longer "over" the button, preventing the click from registering.
Fixed by treating taps as "over" if the finger didn't move significantly, even if the widget moved underneath due to layout shifts.
* Make is_over conditionals clearer
* Fix modal event handling behavior
Everything now works as expected, *except* for Scroll events that seem to
still be received by views beneath the modal, e.g., an underlying PortalList.
* Enable widgets to block scrolling, except within a certain area
* This is important for Modals to prevent scrolling of background widgets
whilst still allowing the inner `content` view to be scrolled.
* Modals are now forcibly full-screen (or rather, full-window)
in order to properly ensure that scrolling-allowed areas
always stay relevant, as the Modal can no longer be contained
within a non-full-window parent widget/view.
* remove errant log statement
