Return Image handle instead of window (EFL)

[JSUYA]

Nice to meet you devs. I'm studying flutter and have a question, so I'm making a sample and writing my opinion here :)

Currently, AddtoApp of flutter-tizen can be implemented by using a window handle. (ecore_wl2, elm_win)

To add the rendered flutter output to the elementary widget, it was not appropriate to use elm_win.
(I tried using other types of windows, but it didn't work as intended. (ELM_WIN_INLINED_IMAGE type of elm_win))

I made a sample by modifying the evas_gl.cc code to use the evas image handle.
The user can get the image handle after set the parent window or parent widget appropriately. And they can add it somewhere.

Below is a sample of this idea.
If a suitable interface and sample code to add parent are presented, users can expect to output FlutterView(?) in EFL-based apps.
(Of course, this is not a nice interface unless multi-instance (maybe FlutterGroup?) is applied.)

sample)

https://github.com/JSUYA/engine/tree/jsuya/flutter-2.8.1-tizen/dev/evas_image

[bwikbs]

@JSUYA
First of all, It's very interesting proposal. Actually, we have a plan to do something similar!
Currently, Its priority is little behind for other urgent issue...
Thank you very much for all the suggestions and sample code. 👍

[swift-kim]

Hi. I'm glad that you finally joined my team and thank you for filing a suggestion! (Maybe this issue is related to #94.)

According to your approach, should the app always pass its window handle (as a parent window) to the embedder regardless of the app's scenario (add to app or normal)?

If so, we might also be able to reduce the launching time overhead by removing the call to elm_win_add in the embedder and reusing the elm window already created by the app. (You don't have to consider this right now.)

[JSUYA]

Hi. I'm glad that you finally joined my team and thank you for filing a suggestion!

Thank you :)

(Maybe this issue is related to #94.)

I will check it.

According to your approach, should the app always pass its window handle (as a parent window) to the embedder regardless of the app's scenario (add to app or normal)?

In this case, we need the parent's handle, which will contain the evas_image, not the window handle. (Of course, it can be a window)
elementary almost always needs a parent when creating a widget. (elm_XXX_add(parent))

If so, we might also be able to reduce the launching time overhead by removing the call to elm_win_add in the embedder and reusing the elm window already created by the app. (You don't have to consider this right now.)

Yes, we don't have to create unnecessary windows. The container to contain the evas image is created in the app code.

[swift-kim]

@JSUYA Thanks for the clarification, but what I meant was: Do you plan to make an app pass an Evas object handle to the embedder even if the app does not use the add to app feature?

[bwikbs]

@JSUYA Just forget everything I said above.. I glanced at your profile and had no idea who you are. 😢
Welcome! & Look forward to working together soon. 😄

[JSUYA]

@JSUYA Thanks for the clarification, but what I meant was: Do you plan to make an app pass an Evas object handle to the embedder even if the app does not use the add to app feature?

If the application does not use add to app feature, we do not need to pass the parent object.
Now embedder's FlutterApp Interface is one. But I think that if we provide the interface for single flutter screen(elm_win or ecore_wl2_window), Flutter-View(elm/evas_object, NUI/View(component)), we will be able to solve this problem(?).

[bbrto21]

related issue flutter-tizen/flutter-tizen#351