Code review comment for lp:~nick-dedekind/mir/trusted_sessions

> Hi! I was asked to comment on the current approach, so here I am. :-)
>
> I'll first recap what Online Accounts needs on a higher level (see also the
> description of bug 1230091):
>
> The Online Accounts ("OA" for brevity) D-Bus service responds to client
> requests, and in response to these requests it's possible that we need to open
> the Online Accounts UI on top of the client application in a modal way:
> without blocking its process execution, but preventing it from getting
> mouse/keyboard input.
>
> While the user is working with the OA window, it may be that we need to start
> other processes; these are not ordinary applications, but account plugins:
> there is a single binary which loads different QML UIs depending on the
> account provider (where provider is "google", "facebook", etc.). Also, the
> apparmor confinement under which the account plugin process is run depends on
> the account provider (we want to confine account plugins which come as part of
> click packages).
>
> Note that different applications can talk to the OA API at the same time, and
> it's possible that at a certain given moment there are two different client
> applications involved in two different trust sessions, with two OA windows
> (each one being modal to one client application) and each one having an
> account plugin UI opened, which might be the same plugin for both sessions, or
> a different one.
>
> We currently produce all the OA UIs from a single process (the OA D-Bus
> service); this bit of implementation can be changed if needed, and we can make
> so that each OA UI window leaves in a different process. This however would
> require more IPC and added complexity, and I believe that when Mir/Unity8 will
> hit the desktop it will anyway have to support the case of a single process
> creating multiple windows, so I hope that "1 pid = 1 window" won't be a
> requirement for the trust sessions.
>
> Considering all the above, the API proposed in this branch doesn't seem to
> provide the functionality we need, since it only accepts PIDs as members of a
> session.
>
>
> With no intention of sounding more expert than what I am, I'll quickly
> describe how my ideal API would look like, while indeed acknowledging that
> other implementations might exist and be better suited:
> - refer to individual windows, not processes or applications
> - API to request a window to be placed as modal of another window (possibly
> created by another process)
> - such request might fail if the calling process is confined and has not been
> authorized
> - API to authorize a process (by APP_ID) to set any of its window as modal to
> a given window
> That is, mainly a couple of methods:
> void Window::setTransientFor(WindowHandle obscuredWindow);
> void Window::allowModalWindowsFromApplication(AppId app);
> The first one for actually doing the reparenting work, and the latter to
> decide who can do that (besides unconfined apps).

As far as I'm aware, we're not doing any Qt API for trust sessions. This will be dealt with by dedicated trusted helpers which use the mir API directly.
[At the moment,] a trusted helper starts a trust session between 2 or more sessions. This list of applications is essentially an "sessions modality" list.
ie.
If trust session children = [app1, app2, app3]
then: sessions will be stacked in order of "last is top"

I'm working on putting session name in the works, but at the moment the qpa does not use this property in any useful manner. (all Qt sourced mir sessions are named "QtUbuntu")