When linting flutter/vulkan/vulkan_window.cc, the call to
GrDirectContext::MakeVulkan is undefined when SK_VULKAN is not defined,
triggering a lint error.
Bug: https://github.com/flutter/flutter/issues/68331
This implements the Gtk hooks required to support multi-step input
methods on Linux. This builds on the support for composing regions
(preedit region in Gtk terminology) added to TextInputModel in
https://github.com/flutter/engine/pull/21682.
Specifically, the following changes are included:
1. Add handler for TextInput.setMarkedTextRegion framework messages: On
any change to the EditableText in the framework, this message is sent
which provides an updated rect (in the local co-ordinates of the
EditableText) for the composing region. If not in composing mode, the
cursor rect is sent.
2. Add handler for TextInput.setEditableSizeAndTransform framework messages:
On any change to the RenderObject underlying the EditableText, an
updated size for the full EditableText widget, as well as an affine
transform matrix from local co-ordinates to Flutter root co-ordinates is
sent.
3. On either of the above messages, we use the transformed composing
rect to compute the cursor position in Gtk window co-ordinates and
inform Gtk, so that it can position any system IM composing window
correctly for on-the-spot composing, such as is used when inputting
Japanese text.
4. Adds handlers for preedit-start, preedit-changed, and preedit-end
signals from Gtk. These are passed on to the TextInputModel.
5. Updates the preedit-commit handler to commit the composing region to
the text or, if not composing, insert new text at the cursor.
6. Updates the handler for TextInput.setEditingState framework messages
to extract the composing range base and extent and pass these on to
TextInputModel.
7. Updates update_editing_state function to set composing base and
extent on text input state updates sent to the framework.
This PR fixes a few small memory leaks in FlTextInputPlugin. All three cases
are creating temporary FlValue instances for lookups and comparison without
ever releasing them.
A version of this macro is present in most code-bases. The use of this macro
must satisfy two requirements:
1: If reached, the process must be terminated in all runtime modes and at all
optimization levels.
2: If the compiler requires a value to be returned from the function,
encountering this macro should not make the compiler insist on a return value
(since the process is about to die anyway).
We used to have a version of this macro that wasn't widely used and didn't
satisfy the two requirements. I have removed the same and another unused macro
in fml/logging.h
Fixes https://github.com/flutter/flutter/issues/68164.
This adds enforcement to the linter that all FLUTTER_NOLINT comments be
of the form:
// FLUTTER_NOLINT: https://github.com/flutter/flutter/issue/ID
Every linter opt-out should have an associated bug describing what issue
it works around so that others can work on eliminating it, or at least
understanding the rationale and whether it's still relevant.
This also reduces the likelihood of inadvertent copy-pasting into new
files either because the author fails to spot it when copying the
copyright block from another file, or assumes that it's necessary for
some subcomponent of the engine.
Bug: https://github.com/flutter/flutter/issues/68273
In an upcoming patch, we'll enable enforcement that all FLUTTER_NOLINT
comments include an issue link. This migrates the remaining uses to that
format.
Bug: https://github.com/flutter/flutter/issues/68273
Snapshots compiled with sound null-safety enabled require changes to the way in
which isolates are launched. Specifically, the `Dart_IsolateFlags::null_safety`
field needs to be known upfront. The value of this field can only be determined
once the kernel snapshot is available. This poses a problem in the engine
because the engine used to launch the isolate at shell initialization and only
need the kernel mappings later at isolate launch (when transitioning the root
isolate to the `DartIsolate::Phase::Running` phase). This patch delays launch of
the isolate on the UI task runner till a kernel mapping is available. The side
effects of this delay (callers no longer having access to the non-running
isolate handle) have been addressed in this patch. The DartIsolate API has also
been amended to hide the method that could return a non-running isolate to the
caller. Instead, it has been replaced with a method that requires a valid
isolate configuration that returns a running root isolate. The isolate will be
launched by asking the isolate configuration for its null-safety
characteristics.
A side effect of enabling null-safety is that Dart APIs that work with legacy
types will now terminate the process if used with an isolate that has sound
null-safety enabled. These APIs may no longer be used in the engine. This
primarily affects the Dart Convertors in Tonic that convert certain C++ objects
into the Dart counterparts. All known Dart Converters have been updated to
convert C++ objects to non-nullable Dart types inferred using type traits of the
corresponding C++ object. The few spots in the engine that used the old Dart
APIs directly have been manually updated. To ensure that no usage of the legacy
APIs remain in the engine (as these would cause runtime process terminations),
the legacy APIs were prefixed with the `DART_LEGACY_API` macro and the macro
defined to `[[deprecated]]` in all engine translation units. While the engine
now primarily works with non-nullable Dart types, callers can still use
`Dart_TypeToNonNullableType` to acquire nullable types for use directly or with
Tonic. One use case that is not addressed with the Tonic Dart Convertors is the
creation of non-nullable lists of nullable types. This hasn’t come up so far in
the engine.
A minor related change is reworking tonic to define a single library target.
This allows the various tonic subsystems to depend on one another. Primarily,
this is used to make the Dart convertors use the logging utilities. This now
allows errors to be more descriptive as the presence of error handles is caught
(and logged) earlier.
Fixes https://github.com/flutter/flutter/issues/59879
This removes most of the remaining FLUTTER_NOLINT comments and opts
these files back into linter enforcement.
I've filed https://github.com/flutter/flutter/issues/68273 to require
that all FLUTTER_NOLINT comments be followed by a GitHub issue URL
describing the problem to be fixed.
* Add multi-step IME support to TextInputModel
This updates the platform-independent TextInputModel to add support for
input method (abbreviated IM or IME) composing regions.
In contrast to languages such as English, where keyboard input is
managed keystroke-by-keystroke, languages such as Japanese require a
multi-step input process wherein the user begins a composing sequence,
during which point their keystrokes are captured by a system input
method and converted into a text sequence. During composing, the user is
able to edit the composing range and manage the conversion from keyboard
input to text before eventually committing the text to the underlying
text input field.
To illustrate this, in Japanese, this sequence might look something like
the following:
1. User types 'k'. The character 'k' is added to the composing region.
Typically, the text 'k' will be inserted inline into the underlying
text field but the composing range will be highlighted in some manner,
frequently with a highlight or underline.
2. User types 'a'. The composing range is replaced with the phonetic
kana character 'か' (ka). The composing range continues to be
highlighted.
3. User types 'k'. The character 'k' is appended to the composing
range such that the highlighted text is now 'かｋ'
4. User types 'u'. The trailing 'k' is replaced with the phonetic kana
character 'く' (ku) such that the composing range now reads 'かく'
The composing range continues to be highlighted.
5. The user presses the space bar to convert the kana characters to
kanji. The composing range is replaced with '書く' (kaku: to write).
6. The user presses the space bar again to show other conversions. The
user's configured input method (for example, ibus) pops up a
completions menu populated with alternatives such as 各 (kaku:
every), 描く (kaku: to draw), 核 (kaku: pit of a fruit, nucleus), 角
(kaku: angle), etc.
7. The user uses the arrow keys to navigate the completions menu and
select the alternative to input. As they do, the inline composing
region in the text field is updated. It continues to be highlighted
or underlined.
8. The user hits enter to commit the composing region. The text is
committed to the underlying text field and the visual highlighting is
removed.
9. If the user presses another key, a new composing sequence begins.
If a selection is present when composing begins, it is preserved until
the first keypress of input is received, at which point the selection is
deleted. If a composing sequence is aborted before the first keypress,
the selection is preserved. Creating a new selection (with the mouse,
for example) aborts composing and the composing region is automatically
committed. A composing range and selection, both with an extent, are
not permitted to co-exist.
During composing, keyboard navigation via the arrow keys, or home and
end (or equivalent shortcuts) is restricted to the composing range, as
are deletions via backspace and the delete key. This patch adds two new
private convenience methods, `editing_range` and `text_range`. The
former returns the range for which editing is currently active -- the
composing range, if composing, otherwise the full range of the text. The
latter, returns a range from position 0 (inclusive) to `text_.length()`
exclusive.
* Move SetComposingLength to TextRange::set_*
Adds set_base, set_extent, set_start, set_end methods to TextRange.
