ubuntu-app-launch doesn't pass arguments to the executable

[Leo Arias]

Many applications currently use command line arguments to run in different modes. For example, we have reminders that receives -s to start using the sandbox, and some other arguments to decide the geometry of the app if it's being run on a platform that has a screen big enough.

The problem is that when launching the app with ubuntu-app-launch reminders -s, that -s will be dropped. u-a-l will just execute the exec line on the desktop file. So if we need to launch evernote with the sandbox, we will need to write a different desktop file.

I find it really useful to be able to launch applications with different modes by passing an argument. It makes it really simple to test the different modes on the same manual testing session. It also makes it simple to automate tests that require certain conditions, for example running the same tests twice on desktop, once in landscape mode and once in portrait mode; that way we will reduce the number of errors we find while running on the real hardware.

We even have a handler for arguments on our API: http://developer.ubuntu.com/api/qml/sdk-14.10/Ubuntu.Components.Arguments/
So it seems that we are encouraging the apps to use it. But then we are not able to launch them easily with those arguments.

Ted thinks that UI apps shouldn't receive command line arguments, and that we should remove that from the API. (I'll ping Ted to comment on this bug so he talks for himself, I might have missed some details on this statement).

Some alternatives are:
- to write desktop files for each argument on the fly during automated tests.
- to include desktop files for alternate modes on the click packages.
- use environment variables instead of arguments.

I'm reporting this bug so we can discuss about the best approach.

[Ted Gould (ted)]

UAL isn't designed to run custom binaries how ever you'd like, it's designed to launch applications. An application is defined with a bunch of different metadata, but one of the key ones is a desktop file. That file defines how to launch the application and is what UAL decides to use for how to launch it. In this way the application can get launched in a consistent manner and is the same thing from device to device.

[Sergio Schvezov (sergiusens)]

I agree with tedg, u-a-l, in the case of testing parameters, they should be fed in some other way, like environment variables.

The nature of the application is so different that maybe those tests parameters require changing the apparmor rules to allow them to work, making it, in some way, a different application (even if the underlying code base is 90% the same).

[dobey (dobey)]

The tricky thing about app confinement, is that command line arguments and environment variables aren't really a good mix for it. An "app" is completely separate from the rest of the system, in the click package world. There are some hooks in click to set up symlinks or such, for other parts of the system to be able to easily find those apps, such as ubuntu-app-launch and the apps scope. But they are not command line applications, and you can't simply just run them from the command line with arbitrary configuration.

For running the tests multiple times on the same server or workstation, with different screen sizes for each test, the best solution would probably be to have something like xvfb or Xnest, for Mir, where a display surface is created at a specific pixel size, and with a specific grid units ratio, to match different pieces of hardware.

[Leo Arias (elopio)]

I'm going to list the commons scenarios, a write what I think it's the best solution for them after the initial discussions we have had.

- Run an application with a specific geometry to simulate a device layout: run MIR or a MIR virtual frame buffer with that geometry and then the app should maximize to that size.

- Run an application communicating with a server that's not production: during the test set up, configure the test bed so it translates the production domain name to an ip or domain we can control, like a staging server of a fake server with hard-coded responses.

- Run an application with test double dependencies (like evernote sandbox, in that it uses an account plugin that's not the same as the production one): make a package for testing that uses the test dependencies. We would have two apps, evernote and evernote-sandbox. The will share almost all the code, only the deps are different.

If we ever need to pass an argument to an app, we could still write an desktop file for it. So far, that doesn't seem like the right solution in any case, but it's good we have the option. And anyway, that's the only solution we can currently implement while all the others are implemented.

This is still open for discussion of course. I'm just trying to make a summary of today's discussion.

[Zsombor Egri (zsombi)]

I must agree Ted and Sergio and also disagree. Whereas in a handheld device the desktop file is the obvious container for all arguments, on a desktop supporting different arguments is a must. And I don't think those should be contained in different desktop files.

However what comes to testing, I do not see it safe to have test-related arguments supported by the app. I'd rather use environment variables for it.

[dobey (dobey)]

@zsombi I must disagree that supporting CLI arguments is a must, in any situation. As we push further to convergence, this may become more evident, but arguments and environment variables are not "the right way" to solve these problems. They are simply the easy way, because we are used to using them, and working in an unsecured environment.

Even for the "actions" support in Unity and that we've ascribed to the .desktop file infrastructure, I'd argue strongly that different command line arguments is the wrong way to do it. Standardized IPC methods would be the best way, similar to how such actions worked on Windows with COM, and developers can easily declare what standard methods it supports, and provide additional methods when needed. These could perhaps encoded in some way in the .desktop file, or some similar manifest file, and the Actions menu built from that and/or live interaction with the app when running.

For testing, and security, the best solution is isolation. Running the app in an environment isolated from the host system, where the test framework controls the environment and the tests poke the app via IPC, a11y, and similar system layers, I think would be the optimal solution.

[Zsombor Egri (zsombi)]

The feature of handling command line arguments exists in the toolkit, thus the bug is invalid for us.