TizenViewElementary: Change the size of view when the size of container changes #302
Conversation
|
Resize test sample https://github.com/JSUYA/gallery/tree/test/flutterview/resize |
…er changes When the size of the container is changed from the outside, the size of FlutterView and the size of the image are changed together. +) Basically, the size of the container is set according to the size of the image. It was enough to set min/max size only for images. After setting the image size for an unknown reason, the container resize callback is called once again. At this time, evas_object_geometry_get() of container_ returns the initially set value and the size backs to the original size. Therefore, we set min/max of container_ together.
| if (self->container_ == object) { | ||
| int32_t width = 0, height = 0; | ||
| evas_object_geometry_get(object, nullptr, nullptr, &width, &height); | ||
| self->OnGeometryChanged(TizenGeometry{0, 0, width, height}); |
There was a problem hiding this comment.
When I introduced this design, I designed it to be processed by delegating everything to FlutterTizenView when the event of view occurs. I want to talk to you more deeply about this. I'll contact you when I get back to the office.
There was a problem hiding this comment.
Already calling FlutterTizenView::OnResize() on OnGeometryChanged.
There was a problem hiding this comment.
Yes, but there is a difference in architecture.
Calling OnGeometryChanged itself is not a delegation. TizenViewBase's derived class must delegate everything to FlutterTizenView when an event occurs. and OnGeometryChanged is a temporary implementation for window channel, it just mimic callback of resize on TizenView. please do not use this.
FlutterDesktopViewRef is a handle that enables the use of FlutterTizenView as a C-APIs. therefore, C-APIs associated with FlutterTizenView should use the public API of FlutterTizenView.
FlutterTizenView is a delegator(Even if there is no interface for delegation, now I think it would be better to add this to prevent confusion.) to handle events on the host(tizen view). events that occur through different types of TizenViews must be delegated to FlutterTizenView for processing.
Furthermore, I'm imagining using the FlutterDeskopViewRef ans APsI to implement view-type embeddings in C# in tool side(flutter-tizen). this means that it will delegate the event processing that occurs in C# to FlutterTizenView through FlutterDeskopViewRef ans APIs. for that, I think it's good to keep this architecture.
Also, we need to decide whether we should consider resizing with rotation of the host app window that has flutter-view,.
Currently, resizing is always using rotation because it was implemented based on a single page app. Maybe we should provide rotation view as a separate Embedder C-API.
There was a problem hiding this comment.
TizenViewBase's derived class must delegate everything toFlutterTizenViewwhen an event occurs.
events that occur through different types of TizenViews must be delegated to
FlutterTizenViewfor processing.
I still don't understand what leaded you to this decision, as I already commented in #292 (comment). In my opinion, FlutterTizenView is for use by any component in the embedder to interact with the underlying Flutter engine or the framework, as its name (FlutterTizenView) implies. Why should TizenView delegate everything to FlutterTizenView? Rather we should relieve interdependency between the two classes.
There was a problem hiding this comment.
@bbrto21
I deleted the offending function OnGeometryChanged() from TizenView class.
And I modified the callback to call the API of the view. And modified I the ResizeWithRotation to do the resize related work.
(I don't think this PR needs to decide if the name ResizeWithRotation is appropriate. If necessary, please change it to an appropriate name through another PR)
There was a problem hiding this comment.
@JSUYA @swift-kim
First of all, thank you for listening to my explanation over offline conversation.
I apologize for not sharing enough beforehand about the architecture I envisioned. and I will try to share the blueprint well while keeping a small PR of entire work.
OnGeometryChanged() is not a method for TizenView, so refactor it to not use it.
| // FIXME | ||
| // This is a temporary implementation that is only used by the window channel. |
There was a problem hiding this comment.
Would you move this comment into TizenWindow too?
…er changes (#302) * TizenViewElementary: Change the size of view when the size of container changes When the size of the container is changed from the outside, the size of FlutterView and the size of the image are changed together. +) Basically, the size of the container is set according to the size of the image. It was enough to set min/max size only for images. After setting the image size for an unknown reason, the container resize callback is called once again. At this time, evas_object_geometry_get() of container_ returns the initially set value and the size backs to the original size. Therefore, we set min/max of container_ together. * TIzenViewBase: Refactoring view resize OnGeometryChanged() is not a method for TizenView, so refactor it to not use it.
…er changes (#302) * TizenViewElementary: Change the size of view when the size of container changes When the size of the container is changed from the outside, the size of FlutterView and the size of the image are changed together. +) Basically, the size of the container is set according to the size of the image. It was enough to set min/max size only for images. After setting the image size for an unknown reason, the container resize callback is called once again. At this time, evas_object_geometry_get() of container_ returns the initially set value and the size backs to the original size. Therefore, we set min/max of container_ together. * TIzenViewBase: Refactoring view resize OnGeometryChanged() is not a method for TizenView, so refactor it to not use it.
3 participants
When the size of the container is changed from the outside,
the size of FlutterView and the size of the image are changed together.
+)
Basically, the size of the container is set according to the size of the image.
It was enough to set min/max size only for images.
After setting the image size for an unknown reason,
the container resize callback is called once again.
At this time, evas_object_geometry_get() of container_ returns
the initially set value and the size backs to the original size.
Therefore, we set min/max of container_ together.