Merge lp:~mterry/ubuntu-app-launch/warn-on-xapp into lp:ubuntu-app-launch/16.04
Status: | Rejected |
---|---|
Rejected by: | dobey |
Proposed branch: | lp:~mterry/ubuntu-app-launch/warn-on-xapp |
Merge into: | lp:ubuntu-app-launch/16.04 |
Prerequisite: | lp:~mterry/ubuntu-app-launch/fix-ftbfs |
Diff against target: |
1337 lines (+760/-123) 16 files modified
CMakeLists.txt (+4/-0) data/com.canonical.UbuntuAppLaunch.xml (+4/-0) debian/changelog (+8/-0) debian/libubuntu-app-launch2.symbols (+3/-0) helpers.c (+133/-22) helpers.h (+7/-2) libubuntu-app-launch/click-exec.c (+0/-13) libubuntu-app-launch/desktop-exec.c (+0/-13) libubuntu-app-launch/ubuntu-app-launch-trace.tp (+18/-24) libubuntu-app-launch/ubuntu-app-launch.c (+124/-26) libubuntu-app-launch/ubuntu-app-launch.h (+41/-2) tests/CMakeLists.txt (+1/-1) tests/exec-util-test.cc (+2/-1) tests/helper-handshake-test.cc (+263/-13) tests/libual-test.cc (+151/-6) tools/ubuntu-app-watch.c (+1/-0) |
To merge this branch: | bzr merge lp:~mterry/ubuntu-app-launch/warn-on-xapp |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
dobey (community) | Needs Resubmitting | ||
PS Jenkins bot (community) | continuous-integration | Approve | |
Review via email: mp+279323@code.launchpad.net |
This proposal supersedes a proposal from 2015-11-24.
Commit message
Allow Unity to prevent an app from starting and give it as long as it wants to figure that out.
Description of the change
Allow Unity to prevent an app from starting and give it as long as it wants to figure that out.
This branch gives Unity the option to prevent an app from launching by blocking on its answer before actually starting the app and then acting on that answer.
Related branches:
https:/
https:/
https:/
== The existing design ==
The current code goes through pains to avoid any knowledge of Unity (despite using the name Unity in several signals). It doesn't connect to it on the bus. And it doesn't restrict who can answer its "I am starting an app" signal.
I'm not sure why it does this, but it does. So the way it communicates is via broadcast signals on the bus. Which gets answered by "someone" (presumably Unity). If there are multiple signal observers on the bus, we continue launching the app as soon as we hear the first response.
It also waits 1s for an answer; if no answer is received, it just launches the app anyway. The signal is more of a courtesy to Unity than a requirement. So if Unity isn't running, exits before it can respond, or is taking too long, UAL just continues.
== New design ==
The new paradigm is that Unity is an approver of which apps can launch. The proximate reason for this MP is that we want to be able to stop legacy apps from launching when not in Desktop mode. But I could imagine other scenarios (parental controls on some apps, or admin privileges needed for some apps, etc). [1]
I also wanted to allow Unity to take as long as it wanted to decide. Because maybe it is taking user input (authenticating as parent maybe) or in the case of a legacy app on the phone, waiting for user to either cancel the app launch or dock the phone (in which case we'd like to continue the app launch).
If Unity is not running, I've assumed we don't want the app to launch (which is a behavior change).
== Changes ==
- So we want to change the API for observers of the "starting" signal to allow for providing an "approved or not" answer. And we want to make it easy to answer in an async manner. Unfortunately, the current API has no state (no objects on which the API acts) to match up callbacks to their answers. So rather than redo the API, I've just added a new API call that app-starting-
- We want to know if Unity is even running (if not, we should reject the app). So I've kept the immediate signal response UnityStartingSi
- As noted above, I've bumped the timeout from 1s to 5s. This is because now we reject by default if the timeout happens, so it's more important that we give unity8 time. And secondly, we're adding an async API, so increasing the potential blocking time shouldn't be as much of a burden.
- We only support listening to the first responder we hear on the bus. This would be easy to extend to support listening to all responders we hear and waiting for all of them to weigh in. But I didn't need that feature yet, so I didn't write it.
- Since we now wait as long as Unity wants, we have to be sensitive to Unity quitting on us. So once we hear UnityStartingSi
- Eventually, Unity gets back to us with a UnityStartingAp
- Consolidating the handshake logic out of click-exec.c and desktop-exec.c has the side effect of fixing a bug where task_setup failed but we already emitted a UnityStartingBr
- I've added an async version of ubuntu_
== Footnotes ==
[1] ubuntu_
Unmerged revisions
- 216. By Michael Terry
-
Fix tests to still use old smaller timeout for convenience
- 215. By Michael Terry
-
Bump timeout to 5s
- 214. By Michael Terry
-
Add async versions of start_application calls
- 213. By Michael Terry
-
fix tabs and revert some unnecessary wording changes
- 212. By Michael Terry
-
Wait for unity to get back to us
- 211. By Michael Terry
-
Allow server-side of handshake to be async by adding ubuntu_
app_launch_ observer_ finish_ app_starting - 210. By Michael Terry
-
Add 'approved' bool parameter to UnityStartingSignal return signal, so that unity could prevent an app from opening
FAILED: Continuous integration, rev:215 jenkins. qa.ubuntu. com/job/ ubuntu- app-launch- ci/21/ jenkins. qa.ubuntu. com/job/ ubuntu- app-launch- wily-amd64- ci/21/console jenkins. qa.ubuntu. com/job/ ubuntu- app-launch- wily-armhf- ci/21/console jenkins. qa.ubuntu. com/job/ ubuntu- app-launch- wily-i386- ci/21/console
http://
Executed test runs:
FAILURE: http://
FAILURE: http://
FAILURE: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/ubuntu- app-launch- ci/21/rebuild
http://