| 2014-12-04 13:30:33 |
Michael Zanetti |
bug |
|
|
added bug |
| 2014-12-04 13:31:45 |
Michael Zanetti |
description |
Currently it is required to pass the --deskopt_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. |
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. |
|
| 2014-12-04 13:32:21 |
Michael Zanetti |
description |
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. |
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. |
|
| 2015-03-17 16:14:21 |
Marco Trevisan (Treviño) |
bug |
|
|
added subscriber Marco Trevisan (Treviño) |
| 2016-06-17 15:24:26 |
Daniel d'Andrada |
bug |
|
|
added subscriber Daniel d'Andrada |
| 2017-03-13 17:20:26 |
Launchpad Janitor |
qtmir (Ubuntu): status |
New |
Confirmed |
|
| 2017-03-13 17:20:26 |
Michał Sawicz |
affects |
qtmir |
qtmir (Ubuntu) |
|
| 2017-03-13 17:20:26 |
Michał Sawicz |
qtmir (Ubuntu): status |
New |
Confirmed |
|
