unity-api-bugs team mailing list archive

[Leo Arias <leo.arias@xxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: autopilot
     Importance: Undecided
         Status: New

** Affects: ubuntu-app-launch
     Importance: Undecided
         Status: New

** Affects: ubuntu-ui-toolkit
     Importance: Undecided
         Status: New

** Also affects: autopilot
   Importance: Undecided
       Status: New

** Also affects: ubuntu-ui-toolkit
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Unity API
bugs, which is subscribed to Ubuntu Application Launcher.
https://bugs.launchpad.net/bugs/1367871

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

Status in Autopilot:
  New
Status in Ubuntu Application Launcher:
  New
Status in Ubuntu UI Toolkit:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/autopilot/+bug/1367871/+subscriptions