make launching apps from command line easier

[Michael Zanetti]

Currently it is required to pass the --desktop_file_hint argument for QtMir to accept an application. This is very cumbersome as it requires to type the full path to /usr/share/applications/ and an existing .desktop file. Additionally this has the possibility to break badly implemented command line parsers when they fail on unknown arguments (even after passing this after --). Combined with a current bug that it only accepts .desktop files in system application directories it breaks running locally built but not installed applications without some hacking around.

Due to our architecture, there is the need to identify applications somehow for various reasons like application matching in the ui, app confinement etc.

So far we came up with those proposals to get around this:

* allow executing arbitrary binaries, by generating the unique identifier based on binary name/path. This would probably break some things, but seems to be "good enough" for quickly running something. Real applications launched from the ui wouldn't use this. Also a way to launch it properly for the required cases would persist (e.g. keeping the --desktop_file_hint but making it optional). There might be considerations if this could be allowed always or just in developer mode.

* Provide a sophisticated launcher that takes a binary only and finds/generates a .desktop file to do the real thing. Something like "launch ./somebinary". This could perhaps create a confined app environment on basedir or CWD and allow passing -u|--unconfined to run the binary unconfined for various purposes (system apps, quick-debugging etc).

Also a combination of the above would be possible.

[Michał Sawicz (saviq)]

I vote for the latter approach, as this would mean keeping our production code free of backdoors. Creating a temporary environment in which to launch a binary so it's regarded as an app by UAL / QtMir's ApplicationManager does not seem too complicated.

I know the SDK team was considering something similar to allow remote debugging, that work could be leveraged there.

[Benjamin Zeller (zeller-benjamin)]

Not sure if that helps in your case, but in the SDK we have a helper script that takes
a click package and hook as argument , installs , runs and uninstalls it.

http://bazaar.launchpad.net/~ubuntu-sdk-team/qtcreator-plugin-ubuntu/trunk/view/head:/share/qtcreator/ubuntu/scripts/qtc_device_applaunch.py

[Benjamin Zeller (zeller-benjamin)]

Since that bug is related to running apps in non standard way, there are some cases we should think abou too:

Testing a application that has no desktop file / click packaging, for example when someone
starts with GUI programming or learns a new toolkit and wants to run the examples that are
shipped with it.

Or maybe someone wants to port a Application to Ubuntu, but does not want to start
with the packaging (which you usually don't)

Debugging:

Right now we have to jump though a few hoops to make debugging on the phone possible, this
is OK for the phone, because we have a UI to set everything up. But as soon as this hits the Desktop we need
to rethink it completely, the steps are right now:

1) Provide a valid click package
2) Inject a debug helper script to enable debugging
3) Inject gdbserver or qml debug switches into the desktop file
4) Install the click package
5) Execute the right application hook with UAL
6) Forward stdin and stdout to files the sdk-launcher can read from
7) Connect with gdb to the gdbserver

Requiring the same for debugging on the Desktop is probably not the way to go as it would force people
to use only the Ubuntu-SDK IDE, which makes not so much sense on the Desktop because of the various
supported toolkits and lanugages.

So we should support multiple ways of starting applications (maybe also scopes):
-> Start an confined application using the UI
-> Start an confined application using the terminal (ubuntu-app-launch)
-> Start an confined application using the terminal in the debugger
-> Start an unconfined application directly from the binary
-> Start an unconfined application directly from the binary in the debugger

Keep in mind that when you start a application manually from the terminal with lets say
launch-unconfined myapp, you know exactly that the application is not confined.

[Michael Zanetti (mzanetti)]

The problem with having only the dedicated launcher creating a run environment is still that it breaks legacy stuff. I'm not sure we can assume every debugger, IDE, multiprocess software can deal with injecting such a tool in between binary launches.

While I agree we need it (to allow confined app debugging and whatnot) I don't think we should prevent the simplistic ./binary case from working at all.

[Benjamin Zeller (zeller-benjamin)]

Another example about a tool some of us use everyday:

bzr explorer .

How would a tool like that get a QtMir connection if
confinement and a desktop file is required?

Also even if started with "launcher bzr ." you would not
get the arguments into the UAL session.

Same with tools like KDiff:
"kdiff file1 file2"

I think we can not reduce the Desktop to UI only .There
are so many more ways to execute applications. And even applications
that sometimes have a UI and sometimes not (bzr using the explorer plugin)

[Gerry Boland (gerboland)]

I fear some BAMF like process matching is unavoidable for situations where shell/upstart are not the ones launching a process.

We can try creating tooling to minimize the impact of the current phablet approach, but we'll never cover every situation, and many people will not want to change from launching gedit by typing "gedit" into a terminal.

[Benjamin Zeller (zeller-benjamin)]

Why would we need some BAMF like process matching? Just do NOT group any
unconfined apps, but show them as extra process.

Basically "If you want your apps to be grouped, start them with ubuntu-app-launch"...

[Marco Trevisan (Treviño) (3v1n0)]

I'd stay away from the BAMF like matching... I mean I've been doing it, and it's not 100% reliable.
While it might be nice at development time, it shouldn't be allowed in production imho.

What probably we should support, is an environment variable and not just a "--desktop_file_hint" thing, that might also break some non-ubuntu-touch native apps args parsing.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.