Merge lp:~dandrader/unity-api/lifecycle into lp:unity-api

Proposed by Daniel d'Andrada
Status: Merged
Approved by: Michał Sawicz
Approved revision: 159
Merged at revision: 154
Proposed branch: lp:~dandrader/unity-api/lifecycle
Merge into: lp:unity-api
Diff against target: 208 lines (+8/-46)
9 files modified
debian/changelog (+6/-0)
include/unity/shell/application/ApplicationInfoInterface.h (+0/-9)
include/unity/shell/application/ApplicationManagerInterface.h (+0/-14)
include/unity/shell/application/CMakeLists.txt (+2/-2)
test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationInfo.cpp (+0/-5)
test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationInfo.h (+0/-2)
test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationManager.cpp (+0/-8)
test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationManager.h (+0/-2)
test/qmltest/unity/shell/application/tst_Application.qml (+0/-4)
To merge this branch: bzr merge lp:~dandrader/unity-api/lifecycle
Reviewer Review Type Date Requested Status
PS Jenkins bot (community) continuous-integration Needs Fixing
Michał Sawicz Approve
Gerry Boland (community) Needs Fixing
Michael Zanetti (community) Approve
Review via email: mp+230091@code.launchpad.net
To post a comment you must log in.
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
Gerry Boland (gerboland) wrote :

I dislike this API as it only makes sense when an Application having 1 surface, which is not going to be true in future.

Why can't we just have the screenshot being obtained by an image provider? Why would Application save its screenshot internally at all? It was useful before QtComp, as it was a cacheing system that made sense at the time, but now I don't see the benefit at all.

Aside: in adding new methods, you need to add them to this QML test: test/qmltest/unity/shell/application/tst_Application.qml

review: Needs Fixing
Revision history for this message
Michael Zanetti (mzanetti) wrote :

> I dislike this API as it only makes sense when an Application having 1
> surface, which is not going to be true in future.

+1

>
> Why can't we just have the screenshot being obtained by an image provider? Why
> would Application save its screenshot internally at all? It was useful before
> QtComp, as it was a cacheing system that made sense at the time, but now I
> don't see the benefit at all.

Well, we need to update it at some point. Where would you save the screenshot otherwise? IMO the Application object is the right place to do so. Actually IMO it should be completely transparent to QML... The MirSurfaceItem should either paint the surface of the screenshot. Not requiring QML to do anything to switch between the two...

>
> Aside: in adding new methods, you need to add them to this QML test:
> test/qmltest/unity/shell/application/tst_Application.qml

+1

Revision history for this message
Michał Sawicz (saviq) wrote :

> > I dislike this API as it only makes sense when an Application having 1
> > surface, which is not going to be true in future.
>
> +1

With more than one surface, we'll need to save surface state and screenshot for all the surfaces I'd think.

> > Why can't we just have the screenshot being obtained by an image provider?
> Why
> > would Application save its screenshot internally at all? It was useful
> before
> > QtComp, as it was a cacheing system that made sense at the time, but now I
> > don't see the benefit at all.
>
> Well, we need to update it at some point. Where would you save the screenshot
> otherwise? IMO the Application object is the right place to do so. Actually
> IMO it should be completely transparent to QML... The MirSurfaceItem should
> either paint the surface of the screenshot. Not requiring QML to do anything
> to switch between the two...

Agreed, the screenshot(s) should be taken on suspension without the shell ever really knowing, so no public API needed ideally?

Revision history for this message
Daniel d'Andrada (dandrader) wrote :

> > Why can't we just have the screenshot being obtained by an image provider?
> Why
> > would Application save its screenshot internally at all? It was useful
> before
> > QtComp, as it was a cacheing system that made sense at the time, but now I
> > don't see the benefit at all.
>
> Well, we need to update it at some point. Where would you save the screenshot
> otherwise? IMO the Application object is the right place to do so. Actually
> IMO it should be completely transparent to QML... The MirSurfaceItem should
> either paint the surface of the screenshot. Not requiring QML to do anything
> to switch between the two...

You have to animate (e.g crossfade) between the surface and the screenshot, and that's done in QML.
Unless you want to move that QML code from unity8 to qtmir, which I don't think it makes sense as unity8 is the guy that takes care of such UI stuff.

Revision history for this message
Daniel d'Andrada (dandrader) wrote :

> Why can't we just have the screenshot being obtained by an image provider? Why
> would Application save its screenshot internally at all? It was useful before
> QtComp, as it was a cacheing system that made sense at the time, but now I
> don't see the benefit at all.

I don't get your comment. That what is happening already. The image provider is just an API between C++ and QML so that QML can use an URL to refer to an QImage held in the C++ side.

Revision history for this message
Michael Zanetti (mzanetti) wrote :

I'd still say we shouldn't need those update methods... The screenshot should be automatically updated before the app is put into suspend and discarded when we have a surface again.

Also do we really need a crossfading between screenshot and surface? Ideally the image shouldn't change when switching from surface to screenshot. The other way round I guess the app just initializes from start again. Not sure we need a crossfade even there as inside apps the screens usually also don't use a crossfade when changing.

review: Needs Information
Revision history for this message
Daniel d'Andrada (dandrader) wrote :

> I'd still say we shouldn't need those update methods... The screenshot should
> be automatically updated before the app is put into suspend and discarded when
> we have a surface again.

Talked to Gerry. There's another way of doing it that doesn't require updateScreenshot() and discardScreenshot() API but still lets unity8 decide when to get it and when to drop it. Working on it now.

> Also do we really need a crossfading between screenshot and surface? Ideally
> the image shouldn't change when switching from surface to screenshot. The
> other way round I guess the app just initializes from start again.

We need to crossfade as there's no guarantee that the screenshot we have will match the contents of the app surface once it's restarted. So we crossfade to mitigate any sudden, dramatic, change.

> Not sure we need a crossfade even there as inside apps the screens usually also don't use
> a crossfade when changing.

Didn't get your comment. But if what you mean is that, for example, some application doesn't animate when switching between tabs or something, then it's the apps problem, not ours. Ie, if some app is doing a bad job it doesn't mean that we should follow suite.

Revision history for this message
Michael Zanetti (mzanetti) wrote :

> > I'd still say we shouldn't need those update methods... The screenshot
> should
> > be automatically updated before the app is put into suspend and discarded
> when
> > we have a surface again.
>
> Talked to Gerry. There's another way of doing it that doesn't require
> updateScreenshot() and discardScreenshot() API but still lets unity8 decide
> when to get it and when to drop it. Working on it now.

But why do you want the shell to be in charge of that? It's not that the shell is the OOM killer. The killing happens behind the scenes, why not just make things work behind the scenes then?

>
> > Also do we really need a crossfading between screenshot and surface? Ideally
> > the image shouldn't change when switching from surface to screenshot. The
> > other way round I guess the app just initializes from start again.
>
> We need to crossfade as there's no guarantee that the screenshot we have will
> match the contents of the app surface once it's restarted. So we crossfade to
> mitigate any sudden, dramatic, change.

Again. We're using sudden, dramatic, life-threatening changes everywhere in the apps. From splash to app, when pushing a page to the PageStack inside the app. Doing a cross fade here would be inconsistent and tell the user that something is different, while the whole point of this is to make the app killing and restarting invisible to the user. Did design request a crossfade here? If not I don't think there should be one.

>
> > Not sure we need a crossfade even there as inside apps the screens usually
> also don't use
> > a crossfade when changing.
>
> Didn't get your comment. But if what you mean is that, for example, some
> application doesn't animate when switching between tabs or something, then
> it's the apps problem, not ours. Ie, if some app is doing a bad job it doesn't
> mean that we should follow suite.

My point is that we should do what the app does as we want to trick the user into thinking he is in the app. Trying to be more clever than the app itself here only makes the cheating more visible.

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
Michael Zanetti (mzanetti) wrote :

> > Didn't get your comment. But if what you mean is that, for example, some
> > application doesn't animate when switching between tabs or something, then
> > it's the apps problem, not ours. Ie, if some app is doing a bad job it
> doesn't
> > mean that we should follow suite.

Also, its not that *some* app doesn't animate, its that all of the apps don't do so because the SDK doesn't do it.

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Needs Fixing (continuous-integration)
Revision history for this message
Daniel d'Andrada (dandrader) wrote :

Updated.

Revision history for this message
Gerry Boland (gerboland) :
review: Approve
Revision history for this message
Michael Zanetti (mzanetti) wrote :

there are test failures

review: Needs Fixing
Revision history for this message
Daniel d'Andrada (dandrader) wrote :

> there are test failures

Fixed. Should have paid attention to Jenkins posts here :/

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :
review: Approve (continuous-integration)
Revision history for this message
Michael Zanetti (mzanetti) wrote :

ack

review: Approve
Revision history for this message
Gerry Boland (gerboland) wrote :

Commit message & debian changelog entry do not match what this MR does.

review: Needs Fixing
Revision history for this message
Michał Sawicz (saviq) wrote :

FWIW if there's a changelog entry, no need for commit message.

Revision history for this message
Michał Sawicz (saviq) :
review: Needs Fixing
lp:~dandrader/unity-api/lifecycle updated
158. By Daniel d'Andrada

Don't touch this stuff, whatever it's used for

Revision history for this message
Daniel d'Andrada (dandrader) :
lp:~dandrader/unity-api/lifecycle updated
159. By Daniel d'Andrada

Updated debian/changelog

Revision history for this message
Daniel d'Andrada (dandrader) wrote :

> Commit message & debian changelog entry do not match what this MR does.

Fixed.

Revision history for this message
Michał Sawicz (saviq) :
review: Approve
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

FAILED: Continuous integration, rev:159
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https://code.launchpad.net/~dandrader/unity-api/lifecycle/+merge/230091/+edit-commit-message

http://jenkins.qa.ubuntu.com/job/unity-api-ci/260/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/unity-api-utopic-amd64-ci/95
    SUCCESS: http://jenkins.qa.ubuntu.com/job/unity-api-utopic-armhf-ci/95
        deb: http://jenkins.qa.ubuntu.com/job/unity-api-utopic-armhf-ci/95/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/unity-api-utopic-i386-ci/95

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/unity-api-ci/260/rebuild

review: Needs Fixing (continuous-integration)

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'debian/changelog'
2--- debian/changelog 2014-08-06 19:32:56 +0000
3+++ debian/changelog 2014-08-21 14:35:01 +0000
4@@ -1,3 +1,9 @@
5+unity-api (7.89) UNRELEASED; urgency=medium
6+
7+ * Remove all mentions to screenshotting from the API
8+
9+ -- Daniel d'Andrada <daniel.dandrada@canonical.com> Fri, 21 Aug 2014 11:33:00 -0300
10+
11 unity-api (7.88+14.10.20140806-0ubuntu1) utopic; urgency=medium
12
13 [ Michal Hruby ]
14
15=== modified file 'include/unity/shell/application/ApplicationInfoInterface.h'
16--- include/unity/shell/application/ApplicationInfoInterface.h 2013-12-11 11:04:11 +0000
17+++ include/unity/shell/application/ApplicationInfoInterface.h 2014-08-21 14:35:01 +0000
18@@ -97,13 +97,6 @@
19 */
20 Q_PROPERTY(bool focused READ focused NOTIFY focusedChanged)
21
22- /**
23- * @brief The URL of the app's screenshot to be used with the image provider.
24- *
25- * Holds the URL for the app's screenshot. This URL will change whenever the screenshot updates.
26- */
27- Q_PROPERTY(QUrl screenshot READ screenshot NOTIFY screenshotChanged)
28-
29 protected:
30 /// @cond
31 ApplicationInfoInterface(const QString &appId, QObject* parent = 0): QObject(parent) { Q_UNUSED(appId) }
32@@ -152,7 +145,6 @@
33 virtual Stage stage() const = 0;
34 virtual State state() const = 0;
35 virtual bool focused() const = 0;
36- virtual QUrl screenshot() const = 0;
37 /// @endcond
38
39 Q_SIGNALS:
40@@ -163,7 +155,6 @@
41 void stageChanged(Stage stage);
42 void stateChanged(State state);
43 void focusedChanged(bool focused);
44- void screenshotChanged(const QUrl &screenshot);
45 /// @endcond
46 };
47
48
49=== modified file 'include/unity/shell/application/ApplicationManagerInterface.h'
50--- include/unity/shell/application/ApplicationManagerInterface.h 2014-03-10 12:40:25 +0000
51+++ include/unity/shell/application/ApplicationManagerInterface.h 2014-08-21 14:35:01 +0000
52@@ -77,7 +77,6 @@
53 m_roleNames.insert(RoleStage, "stage");
54 m_roleNames.insert(RoleState, "state");
55 m_roleNames.insert(RoleFocused, "focused");
56- m_roleNames.insert(RoleScreenshot, "screenshot");
57
58 connect(this, SIGNAL(rowsInserted(QModelIndex, int, int)), SIGNAL(countChanged()));
59 connect(this, SIGNAL(rowsRemoved(QModelIndex, int, int)), SIGNAL(countChanged()));
60@@ -100,7 +99,6 @@
61 RoleStage,
62 RoleState,
63 RoleFocused,
64- RoleScreenshot,
65 };
66
67 /// @cond
68@@ -185,18 +183,6 @@
69 */
70 Q_INVOKABLE virtual bool stopApplication(const QString &appId) = 0;
71
72- /**
73- * @brief Update the screenshot for an application.
74- *
75- * NOTE: Normally the ApplicationManager will update screenshots unfocusing or focusing apps,
76- * However, in cases where you need to show the screenshot while the application is still focused,
77- * you can request the ApplicationManager to update it now.
78- *
79- * @param appId The application for which the screenshot should be updated.
80- * @returns True if the screenshot update operation was scheduled successfully, false otherwise (i.e. the given appId could not be found)
81- */
82- Q_INVOKABLE virtual bool updateScreenshot(const QString &appId) = 0;
83-
84 Q_SIGNALS:
85 /// @cond
86 void countChanged();
87
88=== modified file 'include/unity/shell/application/CMakeLists.txt'
89--- include/unity/shell/application/CMakeLists.txt 2014-03-04 10:50:44 +0000
90+++ include/unity/shell/application/CMakeLists.txt 2014-08-21 14:35:01 +0000
91@@ -7,8 +7,8 @@
92
93 set(UNITY_API_LIB_HDRS ${UNITY_API_LIB_HDRS} ${headers} ${internal_headers} PARENT_SCOPE)
94
95-set(VERSION 2)
96-set(PKGCONFIG_NAME "unity-shell-appliction")
97+set(VERSION 3)
98+set(PKGCONFIG_NAME "unity-shell-application")
99 set(PKGCONFIG_DESCRIPTION "Unity shell Application APIs")
100 set(PKGCONFIG_REQUIRES "Qt5Core")
101 set(PKGCONFIG_FILE unity-shell-application.pc)
102
103=== modified file 'test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationInfo.cpp'
104--- test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationInfo.cpp 2013-12-11 11:28:22 +0000
105+++ test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationInfo.cpp 2014-08-21 14:35:01 +0000
106@@ -54,11 +54,6 @@
107 return m_icon;
108 }
109
110-QUrl MockApplicationInfo::screenshot() const
111-{
112- return m_screenshot;
113-}
114-
115 ApplicationInfoInterface::Stage MockApplicationInfo::stage() const
116 {
117 return m_stage;
118
119=== modified file 'test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationInfo.h'
120--- test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationInfo.h 2013-12-11 11:28:22 +0000
121+++ test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationInfo.h 2014-08-21 14:35:01 +0000
122@@ -36,7 +36,6 @@
123 QString name() const;
124 QString comment() const;
125 QUrl icon() const;
126- QUrl screenshot() const;
127
128 ApplicationInfoInterface::Stage stage() const;
129 void setStage(ApplicationInfoInterface::Stage stage);
130@@ -52,7 +51,6 @@
131 QString m_name;
132 QString m_comment;
133 QUrl m_icon;
134- QUrl m_screenshot;
135 ApplicationInfoInterface::Stage m_stage;
136 ApplicationInfoInterface::State m_state;
137 bool m_focused;
138
139=== modified file 'test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationManager.cpp'
140--- test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationManager.cpp 2014-05-23 08:35:43 +0000
141+++ test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationManager.cpp 2014-08-21 14:35:01 +0000
142@@ -66,8 +66,6 @@
143 return item->state();
144 case RoleFocused:
145 return item->focused();
146- case RoleScreenshot:
147- return item->screenshot();
148 }
149
150 return QVariant();
151@@ -138,9 +136,3 @@
152 Q_UNUSED(appId)
153 return true;
154 }
155-
156-bool MockApplicationManager::updateScreenshot(const QString &appId)
157-{
158- Q_UNUSED(appId)
159- return true;
160-}
161
162=== modified file 'test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationManager.h'
163--- test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationManager.h 2014-03-10 12:34:16 +0000
164+++ test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationManager.h 2014-08-21 14:35:01 +0000
165@@ -57,8 +57,6 @@
166
167 Q_INVOKABLE bool stopApplication(const QString &appId);
168
169- Q_INVOKABLE bool updateScreenshot(const QString &appId);
170-
171 private:
172 QList<MockApplicationInfo*> m_list;
173 };
174
175=== modified file 'test/qmltest/unity/shell/application/tst_Application.qml'
176--- test/qmltest/unity/shell/application/tst_Application.qml 2014-03-10 12:34:16 +0000
177+++ test/qmltest/unity/shell/application/tst_Application.qml 2014-08-21 14:35:01 +0000
178@@ -69,7 +69,6 @@
179 { enum: "RoleStage" },
180 { enum: "RoleState" },
181 { enum: "RoleFocused" },
182- { enum: "RoleScreenshot" },
183 ];
184 }
185
186@@ -89,7 +88,6 @@
187 { tag: "ApplicationManager.roles[stage]", role: "stage", type: "number" },
188 { tag: "ApplicationManager.roles[state]", role: "state", type: "number" },
189 { tag: "ApplicationManager.roles[focused]", role: "focused", type: "boolean" },
190- { tag: "ApplicationManager.roles[screenshot]", role: "screenshot", type: "object" },
191 ];
192 }
193
194@@ -113,7 +111,6 @@
195 { tag: "ApplicationManager.methods[unfocusCurrentApplication]", method: "unfocusCurrentApplication" },
196 { tag: "ApplicationManager.methods[startApplication]", method: "startApplication" },
197 { tag: "ApplicationManager.methods[stopApplication]", method: "stopApplication" },
198- { tag: "ApplicationManager.methods[updateScreenshot]", method: "updateScreenshot" },
199 ];
200 }
201
202@@ -146,7 +143,6 @@
203 { tag: "ApplicationInfo.properties[stage]", property: "stage", type: "number" },
204 { tag: "ApplicationInfo.properties[state]", property: "state", type: "number" },
205 { tag: "ApplicationInfo.properties[focused]", property: "focused", type: "boolean" },
206- { tag: "ApplicationInfo.properties[screenshot]", property: "screenshot", type: "object" },
207 ];
208 }
209

Subscribers

People subscribed via source and target branches

to all changes: