Subject: Fun with Unity8

From: Daniel van Vugt <[email-masked]>
Date: Fri, 18 Sep 2015 12:01:42 +0800

Some might have figured this out already, but you can actually trick 
Unity8 into accepting regular Mir clients like those from the mir-demos 
package. All you need to do is hide the magic desktop_file_hint string 
on the command line in such a way that the client itself does not reject it:

mir_demo_client_egltriangle -f--desktop_file_hint=unity8
mir_demo_client_progressbar 20--desktop_file_hint=unity8
mir_demo_client_fingerpaint -w--desktop_file_hint=unity8
mir_demo_client_target -n--desktop_file_hint=unity8
mir_demo_client_eglplasma -f--desktop_file_hint=unity8
mir_demo_client_eglsquare -n -- --desktop_file_hint=unity8

Admittedly that's a bit hackish. So coming in Mir 0.16.0 more of the 
demo clients will understand the '--' option allowing for graceful 
command line augmentation. Although it would be even better if Unity8 
didn't have the requirement.

- Daniel

---

From: Michał Sawicz <[email-masked]>
Date: Fri, 18 Sep 2015 09:01:21 +0200

> didn't have the requirement.

It doesn't. It requires a way to identify a client to be an app, to read
metadata for it. And that requirement will stay, is generally fulfilled
by ubuntu-app-launch, and --desktop-file-hint was a hack that we should
get rid of soon. I don't think there's anything that relies on it any more.

Not sure what's the status of that, but there were plans in the SDK of a
wrapper launcher that would take care of all those details, so that to
unity8 the client looks like any other. With it, you'd be able to launch
any Mir client wrapped with that, having added some meaningful command
line options.

Another way to identify we were considering is via the apparmor profile
an app is launched under, so that upstart/ubuntu-app-launch could be
taken out of the equation, but we've not confirmed that's our way forward.

-- 
Michał Sawicz <[email-masked]>
Canonical Ltd.

---

From: Daniel van Vugt <[email-masked]>
Date: Fri, 18 Sep 2015 15:05:17 +0800

Sounds like an improvement, thanks. In the long term though, I think you 
will find power users (and even some apps) want to launch non-Qt apps by 
simply executing them. Eventually (as with any other desktop OS) they 
will need to /just work/. So any wrapper will need to go away.

---

From: Michał Sawicz <[email-masked]>
Date: Fri, 18 Sep 2015 09:13:22 +0200

> will need to /just work/. So any wrapper will need to go away.

It's not about Qt or not. The shell requires to uniquely and reliably
identify a client. I can't see a way for this to happen securely without
a trusted third-party (today that's ubuntu-app-launch, it might be
apparmor).
Apps aren't able to directly launch other apps, they have to request an
app to be launched (generally via opening a URL), it's the user that
will ultimately decide whether they allow that or not.

Those are all security features that we might allow "power users" to
lift via a setting or similar, but will be the default behaviour for the
foreseeable future.

---

From: Daniel van Vugt <[email-masked]>
Date: Fri, 18 Sep 2015 15:15:17 +0800

For mobile it totally makes sense.

For desktop I think you will find people will want to run 
"unsigned/untrusted" "legacy" apps quite a lot :)

---

From: Thomas Voß <[email-masked]>
Date: Fri, 18 Sep 2015 09:25:55 +0200

> "unsigned/untrusted" "legacy" apps quite a lot :)

Maybe, and if a terminal app is unconfined/unconditionally trusted,
that property would extend to applications that are started from
within
the terminal app without mediation by a trusted third party. However,
the mediated launching approach has been put in place on purpose.
If the experience is suboptimal we should rather focus on making it
easier to use from the terminal than proposing a workaround.

The launcher infrastructure will gain even more significance going
forward, e.g. setup of cgroups to tightly control resource usage.

> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel