Refactor libwindowmanager and libhomescreen out of WAM

We discussed this task and the current platform in SAT meetings on Dec 11[1] and Dec 13 and had the plan for the future[2].

As we all agreed that we close this ticket since we have the concrete plan to support it instead of having the integration code for libhomescreen and libwindowmanager, I close this ticket.

Thanks for having the discussion and setting up the plan.

[1] https://wiki.automotivelinux.org/agl-sat-meetings#december_11_2018

[2] https://confluence.automotivelinux.org/display/HF/HMI+Architecture+Diagram

@knimitz, thanks for the comment.

> One question. what is the status of application ? You mean surface ID?

I mean the status of application is something like active/inactive/suspend/resume/destroy.

> In the chromium model, I guess Window Manager can't do window management ? Chromium also does window management, doesn't it ? For example, user touches the next task bar, I guess core process sends some signals to the application then switch to it. Then How does chromium changes to the next application(surface) in HMI Framework ?

WAM and Chromium WebBrowser has different integration.

For WAM, we expect Chromium also can be managed using Window manager and each WebApp has its own surface ID and role name. So, that's why WAM is integrated with libWindowManager.

In case of Chromium WebBrowser, Chromium manages tabs, toolbar and sub menu through internal manager and Chromium WebBrowser is using runxdg now.

So, we thought  WebBrowser(which is using runxdg) and WAM has duplicate code.

@Tadao Tanikawa, thanks for the comment.

> > On top of that, Qt-like APIs should wrap the new library, and be added to QtAGLExtras module.
> Therefore, I strongly don't agree with this about proposed approach on github so far.

> > This library should make life easy for people willing to port their applications to AGL.approach is not
> In my understanding, your current approach is not fit this purpose.

OK. As the integration we have(WebBrowser and WAM) has redundant code for integration, we couldn't think that's special case and we thought it's might be required for others. Now we understand.

Today, we have SAT meeting. I know it's late time in JST but I hope we can discuss this issue together.

Thanks all.

Basically, xdg-launcher is a special architecture to launch application which cannot be link both libwm and libhs. E.g. In order to launch chromium browser binary on the AGL Demo HomeScreen without any modification of chromium browser's source code, binary and library linkage.

This is not usual for applications compatible with AGL Demo WM/HS (which means using libwm and libhs and expected running on AGL Demo HomeScreen).

> On top of that, Qt-like APIs should wrap the new library, and be added to QtAGLExtras module.
Therefore, I strongly don't agree with this about proposed approach on github so far.

> This library should make life easy for people willing to port their applications to AGL.approach is not
In my understanding, your current approach is not fit this purpose.

Sorry for late response.

> 1) xdg-launcher will disappear?

> If yes, could you let me know how to supports the applications which are using xdg-launcher now? HMI Framework has a plan to support it?

Probably, it doesn't disappear. AGL needs it to launch xdg applications without modifying implementation for HMI Framework.

> 2) The current WAM integration should be changed without libhomescreen and libwindowmanager? WDYT?

IMHO, yes, but It depends on the your design. Creating wapper library on those library is one idea.

But if the interface of libwindowmanager and libhomescreen changes, libappbridge should also changes. It's not good.

> 3) If WAM uses only ilmControl, not libhomescreen and limwindowmaanger, can we manage the status of the applications?

No, using ilmControl is the problem in my opinion. So let's remove the dependency. I will push changes to window manager to make xdg-runcher not depending on ilmControl.

One question. what is the status of application ? You mean surface ID?

> 4) Chromium is based on multi processes and threads model. So, each Web application works based on multiple processes/threads. If there are some concerns or worries or policies related to having more than 2 threads, could you let me know?

I'm not sure about Chromium architecture but.... If Window Manager changes visibility of a surface which belongs to the chromium core process, weston removes the surface from the rendering list. This means the surface can't get any signals from weston through wayland then stop rendering. In the chromium model, I guess Window Manager can't do window management ? Chromium also does window management, doesn't it ? For example, user touches the next task bar, I guess core process sends some signals to the application then switch to it. Then How does chromium changes to the next application(surface) in HMI Framework ?  

I saw the patch set in gerrit. I agree with Tanikawa-san's comment. It is better to create library in xdg-runcher repository. How about creating library in xdg-runcher library ?

Hi @knimitz, thanks for looking into it in depth.

If xdg-launcher is just for workaround, maybe the problem might be started from that WAM was integrated with the reference to it. As WAM has been integrated with the redundant code from xdg-launcher for using libhomescreen and libwindowmanager, we thought that we need to remove the redundancy and keep code efficiency. Sorry for the lack of understanding about history.

WAM is to manage applications based on Web and it could support multiple applications like some media apps like youtube, some game apps or some automotive control apps. I think we could assume that it's something similar to launcher.

WAM handles to launch and activateWindow for Web applications when it gets 'Event_TapShortcut' which is getting from libHomeScreen now. Even if WAM doesn't handle suspend/resume for the applications for now, I think it could handle those cases as well later. Web Application could be suspend by some native application launched. Maybe it could be the case that a user watches youtube video and then moves out to the main screen even if the video is not done. In that case, youtube video should be suspended. So, I think it could need to get some status events like active/inactive which are getting from LibWindowmanager now. I'm not sure actually. Maybe AGL has some other solution to manage this suspend and resume state.

I have some questions here.

1) xdg-launcher will disappear?

If yes, could you let me know how to supports the applications which are using xdg-launcher now? HMI Framework has a plan to support it?

2) The current WAM integration should be changed without libhomescreen and libwindowmanager? WDYT?

3) If WAM uses only ilmControl, not libhomescreen and limwindowmaanger, can we manage the status of the applications?

4) Chromium is based on multi processes and threads model. So, each Web application works based on multiple processes/threads. If there are some concerns or worries or policies related to having more than 2 threads, could you let me know?

Sorry for the bunch of questions at once but it will be a big help if we could understand the current status and plan.

Thanks,