Support tizen-core window - #195
Conversation
Introduce a use_tcore GN flag (surfaced as the --use-tcore build option)
that switches the window and input-method backends from Ecore/ecore_wl2
to the tizen-core-wl / tizen-core-imf APIs.
- Add tizen_window_tcore_wl and tizen_input_method_context_tcore,
selected in BUILD.gn when use_tcore is set.
- Reimplement the clipboard on tizen-core-wl for tcore builds.
- Expose the native window handle via FlutterDesktopViewGetNativeHandle,
and document that --use-tcore builds return a tizen_core_wl_window_h
while default builds return an Ecore_Wl2_Window*.
- Install the tizen-core-* sysroot packages for Tizen 10.0 and above.
- Reject --use-tcore on Tizen versions below 10.
Extract the libvd-win-util.so access shared by both window backends into
TizenWindowUtil (tizen_window_util.{h,cc}). The TV profile cursor,
mouse-pointer and unsupported-toast helpers each used to dlopen the
library, resolve its symbols and dlclose it inline, so adding the tcore
backend would have duplicated that block eight times. The new class
resolves the six symbols once per instance and keeps the existing
behaviour, including bailing out with the feature disabled when the
library or a symbol is unavailable.
Squashed from flutter-tizen#170 and rebased onto master. The DALI/NUI sysroot
packages removed upstream are not reintroduced, and the work-in-progress
key-event trace logging is dropped.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b9e9385909
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| GList* list = g_list_append(nullptr, info); | ||
| tizen_core_wl_window_set_keygrab_list(tcore_wl_window_, list); |
There was a problem hiding this comment.
When the tcore backend initializes a view, FlutterTizenView passes all 28 bindable system keys to this method, but each iteration replaces the window's key-grab list with a new singleton list. Consequently only the final key (XF86Exit) remains grabbed and TV remote/media keys such as Back, Menu, and Play can be intercepted by the system instead of reaching Flutter. Construct one GList containing every tizen_core_wl_keygrab_info_h and call the list setter once.
Useful? React with 👍 / 👎.
| if (self->input_method_context_ && | ||
| self->input_method_context_->IsInputPanelShown()) { | ||
| handled = | ||
| self->input_method_context_->HandleTcoreWlEventKey(event, true); |
There was a problem hiding this comment.
When a text field is focused but the software input panel is hidden—most notably when typing with a physical keyboard—this condition bypasses tizen-core IMF and sends every key directly to Flutter. The ecore backend deliberately filters keys whenever editing is active (while excluding navigation/system keys), so the new backend loses dead-key composition, IME commits, and pre-edit updates in this common scenario; it also misses keys during the WILL_SHOW state because IsInputPanelShown() recognizes only SHOW.
Useful? React with 👍 / 👎.
| size_t data_length = strlen(data); | ||
| size_t buffer_size = len; |
There was a problem hiding this comment.
For a DATA_READY event whose payload occupies exactly len bytes without a trailing NUL, strlen(data) reads past the buffer before the subsequent length comparison can constrain it, potentially crashing or exposing adjacent memory while pasting. The API already supplies the authoritative byte count, so construct the string directly from data and len rather than scanning for a terminator.
Useful? React with 👍 / 👎.
| packages = base_packages + unified_packages | ||
| if api_version > 10.0: | ||
| packages += tcore_packages |
There was a problem hiding this comment.
At exactly API 10.0 this condition omits all tizen-core headers and libraries from the generated sysroot, while tools/gn explicitly accepts --api-version 10.0 --use-tcore and the nearby package declaration says these dependencies are available for 10.0 and above. A freshly generated 10.0 sysroot therefore cannot compile the accepted tcore configuration; either include these packages with >= 10.0 or reject 10.0 consistently.
Useful? React with 👍 / 👎.
| tizen_core_wl_event_key_get_keysymbol(ev, &keysymbol); | ||
| if (keysymbol) { | ||
| tizen_core_imf_event_key_set_string(imf_key, keysymbol); | ||
| free(keysymbol); |
There was a problem hiding this comment.
For printable keys whose symbol name differs from their text, such as period versus ., this places the symbol name in the IMF event's string field. The mapping documented and used by the new window handlers is that tcore keysymbol corresponds to Ecore's key, while tcore compose corresponds to Ecore's printable string; the existing IMF backend likewise sends those as separate fields. Passing keysymbol as the string can therefore make the input method process or commit names such as period instead of the typed character.
Useful? React with 👍 / 👎.
| TizenInputMethodContext::~TizenInputMethodContext() { | ||
| UnregisterInputPanelEventCallback(); | ||
| UnregisterEventCallbacks(); |
There was a problem hiding this comment.
If tizen_core_imf_context_create fails, the constructor deliberately returns with imf_context_ == nullptr, but destruction unconditionally calls both unregister helpers, which assert that the context is non-null and then invoke tizen-core IMF APIs with that null handle. This turns a recoverable IMF initialization failure into an assertion failure in debug builds and potentially invalid API calls in release builds; mirror the existing ecore backend's null guards before unregistering.
Useful? React with 👍 / 👎.
| if (tizen_core_wl_init() != TIZEN_CORE_WL_ERROR_NONE || | ||
| tizen_core_wl_display_create(&display_) != TIZEN_CORE_WL_ERROR_NONE || | ||
| tizen_core_wl_display_connect(display_, nullptr) != | ||
| TIZEN_CORE_WL_ERROR_NONE) { | ||
| FT_LOG(Error) << "Failed to connect display for clipboard."; | ||
| display_ = nullptr; | ||
| return; |
There was a problem hiding this comment.
When tizen-core initialization, display creation, or display connection fails, this constructor returns with display_ == nullptr, but the TizenClipboard object remains installed in PlatformChannel; subsequent Clipboard.setData, getData, or hasStrings calls pass that null handle to tizen-core APIs (and SetData unconditionally flushes it). Track initialization failure and make these methods fail safely, rather than leaving a callable but invalid clipboard instance.
Useful? React with 👍 / 👎.
1 participant
Add --use-tcore option for window / input-method backend on tizen-core-wl + tizen-core-imf instead of Ecore / ecore_wl2, so the embedder keeps working on images where EFL is deprecated. Off by default; --use-tcore (GN use_tcore), rejected below Tizen 10.0.
tools/gn ... --api-version 11.0 --use-tcore --target-dir tizen_arm64_11.0Artifact list is unchanged: the same six libraries are rebuilt from the same template("embedder") with different backend sources and libs. No new target, no new public API.
*Only exercised on Tizen 11.