-
Notifications
You must be signed in to change notification settings - Fork 17
Refactor embedder and introduce FlutterTizenView #278
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
efbfa7c to
2369967
Compare
| std::unique_ptr<KeyEventHandler> key_event_handler_; | ||
|
|
||
| // An event dispatcher for Ecore mouse events. | ||
| std::unique_ptr<TouchEventHandler> touch_event_handler_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The event handlers are not engine dependent now
I think It is better to depend on something that can be hosts to a flutter-tizen, such as a Window or any UI toolkit component.
|
I checked all flutter-tizen app types on the emulators and devices using this PR.(includes window_channel behavior) |
| std::filesystem::path aot_library_path_; | ||
|
|
||
| // Custom entrypoint in the Dart project | ||
| std::string custom_dart_entrypoint_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this for? I mean.. What scenario was it made for? I thought this was necessary for a certain scenario... I wonder what it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A most typical scenario is a multi-packaging app.
this is not a new feature, it has just been refactored. please see this
Is there any special reason for this? |
swift-kim
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you say "engine" in this embedder codebase, it normally refers to an instance of the Flutter engine wrapper (FlutterTizenEngine) and you don't typically need to prefix it with flutter_tizen_ or FlutterTizen in most contexts. The same may apply to FlutterTizenView and FlutterTizenWindow instances.
The overall direction of this change looks good to me. We'll just need some more clarifications and style fixes.
For APIs based on a specific handle, it is natural to start names with that type in C. |
Thank you for review. I've update PR based on your comments. |
Thank you for helping me understand the terms used in the project! |
| // FIXME : evas_object_geometry_get() and ecore_wl2_window_geometry_get() are | ||
| // not equivalent. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you elaborate on how they are different?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's suppose the window is initialized as follows { width: 720, height: 1280 }, In this situation, depending on the rotation, these show the following results:
When the window rotation is 90 or 270 degree
evas_object_geometry_get returns: { width: 1280, height: 720 }
but
ecore_wl2_window_geometry_get returns: { width: 720, height: 1280 }
| constexpr char kExitKey[] = "XF86Exit"; | ||
|
|
||
| // Keys that should always be handled by the app first but not by the system. | ||
| const std::vector<std::string> kBindableSystemKeys = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This constant is not being used.
Where do you think BindKeys should be called? In this class (in the constructor)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly! This is my mistake. Thank you for finding this out.
| delta_y * scroll_offset_multiplier, timestamp, device_kind, device_id); | ||
| } | ||
|
|
||
| void FlutterTizenView::OnKey(Ecore_Event_Key* event, bool is_down) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This class (FlutterTizenView) is an abstraction layer between the platform window and Flutter, so it's expected to be platform type agnostic. Do you plan to refactor this part again in the future? Should we wrap this type (Ecore_Event_Key) into another type that contains all information required by TextInputChannel, PlatformViewChannel, and KeyEventChannel, or just extract the values and pass them as arguments (just like KeyboardHook() of the Windows embedder)?
Note) Refactoring the input system is out of scope of this PR. I just want to hear your thoughts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right. actually, I wanted to refactor handling key events similar to the point event in this PR.
However, I thought that this was related to input method context and it lead too many additional changes. so I didn't do it.
I think this is the part that must be refactored. I plan to gradually refactor Embedder including this and develop new feature related View.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, improving the input system is also related to the issue #221. We'll revisit this topic soon.
* This is Intial commit to refactor engine using View concept. Signed-off-by: Boram Bae <boram21.bae@samsung.com>
* FlutterTizenView is more suitable for top-level graphics-related interfaces than FlutterTizenEngine. Signed-off-by: Boram Bae <boram21.bae@samsung.com>
* Name of APIs based on handle must start with handle type name. Signed-off-by: Boram Bae <boram21.bae@samsung.com>
* This is initial implementation based on ecore. * There is a lot of to-do things (event handler, rework based on enligntment). Signed-off-by: Boram Bae <boram21.bae@samsung.com>
* Touch event handling is now dependent on FlutterTizenWindow and FlutterTizenView. Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
* Remove KeyEventHandler * Add key event hander to FlutterTizenWindow impl Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
* remove a prefix "Flutter" Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
* If view is not specified, the engine is run in headless mode. Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Signed-off-by: Boram Bae <boram21.bae@samsung.com>
swift-kim
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks good to me, but I have not tested the changes on real devices. Thank you for your hard work.
* Introduce FlutterTizenView. It is a delegate for the flutter rendering host. and it provides interfaces. * Introduce TizenView. it abstracts the platform window and it provides interfaces. Responsibilities of TizenRenderer is reduced, and those responsibilities are transferred to TizenWindow and FlutterTizenView. * Rename the Flutter-tizen C-APIs. this change requires an update of flutter-tizen and plugin too. * The engine runs as headless mode by default now. Signed-off-by: Boram Bae <boram21.bae@samsung.com>
|
contribute to flutter-tizen/flutter-tizen#351 |
* Introduce FlutterTizenView. It is a delegate for the flutter rendering host. and it provides interfaces. * Introduce TizenView. it abstracts the platform window and it provides interfaces. Responsibilities of TizenRenderer is reduced, and those responsibilities are transferred to TizenWindow and FlutterTizenView. * Rename the Flutter-tizen C-APIs. this change requires an update of flutter-tizen and plugin too. * The engine runs as headless mode by default now. Signed-off-by: Boram Bae <boram21.bae@samsung.com>
* Introduce FlutterTizenView. It is a delegate for the flutter rendering host. and it provides interfaces. * Introduce TizenView. it abstracts the platform window and it provides interfaces. Responsibilities of TizenRenderer is reduced, and those responsibilities are transferred to TizenWindow and FlutterTizenView. * Rename the Flutter-tizen C-APIs. this change requires an update of flutter-tizen and plugin too. * The engine runs as headless mode by default now. Signed-off-by: Boram Bae <boram21.bae@samsung.com>
Furthermore, I plan to gradually add flutter-tizen C-APIs that allow implementing views at Embedding using FlutterTizenView.
P.S I'm sorry for making such a big diff, but there's not much difference in behaviors.