Merge lp:~gerboland/unity-api/surfaceSizerCallback into lp:unity-api
| Status: | Work in progress |
|---|---|
| Proposed branch: | lp:~gerboland/unity-api/surfaceSizerCallback |
| Merge into: | lp:unity-api |
| Prerequisite: | lp:~dandrader/unity-api/lifecycle |
| Diff against target: |
613 lines (+448/-6) (has conflicts) 11 files modified
debian/changelog (+41/-1) include/unity/shell/application/ApplicationManagerInterface.h (+35/-0) include/unity/shell/application/CMakeLists.txt (+2/-2) include/unity/shell/application/Mir.h (+76/-0) include/unity/shell/application/MirSurfaceInterface.h (+114/-0) include/unity/shell/application/MirSurfaceItemInterface.h (+151/-0) test/qmltest/mocks/plugins/Unity/Application/CMakeLists.txt (+1/-1) test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationManager.cpp (+17/-1) test/qmltest/mocks/plugins/Unity/Application/Mocks/MockApplicationManager.h (+4/-0) test/qmltest/mocks/plugins/Unity/Launcher/CMakeLists.txt (+1/-1) test/qmltest/unity/shell/application/tst_Application.qml (+6/-0) Text conflict in debian/changelog |
| To merge this branch: | bzr merge lp:~gerboland/unity-api/surfaceSizerCallback |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Albert Astals Cid (community) | code | Approve on 2015-01-15 | |
| PS Jenkins bot | continuous-integration | 2014-08-21 | Approve on 2015-01-13 |
| Michał Sawicz | 2014-08-21 | Approve on 2014-08-21 | |
|
Review via email:
|
|||
This proposal supersedes a proposal from 2014-08-11.
Commit Message
AppMan: add surfaceAboutToB
Description of the Change
AppMan: add surfaceAboutToB
* Are there any related MPs required for this MP to build/function as expected? Please list.
https:/
https:/
* Did you perform an exploratory manual test run of your code change and any related functionality?
Y
| Gerry Boland (gerboland) wrote : | # |
| Michał Sawicz (saviq) wrote : | # |
Oh and document the signature of the callable please. Will it get info about fullscreen, for example?
I wonder if instead we should just pass availableGeometry, with Mir being responsible for policy, should we involve the shell like this?
| Gerry Boland (gerboland) wrote : | # |
> Oh and document the signature of the callable please. Will it get info about
> fullscreen, for example?
Sadly not, I need to add a feature request for Mir for that. IMO the surface type and other info that we get from a standard Mir surface would be good info to have, opposed to this limited subset.
> I wonder if instead we should just pass availableGeometry, with Mir being
> responsible for policy, should we involve the shell like this?
I dislike this idea, as effectively we'd need to educate Mir about the entire QML scene: which areas are off-limits for a non-fullscreen surfaces, what to do for surfaces of different types, stages, etc. Defining a vocabulary for that would be a nightmare IMO. And if Mir makes a decision that shell doesn't like, shell will immediately impose its will anyway - so where's the gain?
Policy I hope to define in Mir relate more to clients expectations, I want to ensure that client surfaces behave in a consistent way across mir server implementations. Shells should treat client surfaces in ways that they expect, that parent/child relationship is obeyed, focus handing is correct, input is delivered to the correct surface, siblings can attach to eachother/their parent and stay there, things like that.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:161
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
FAILED: Continuous integration, rev:162
http://
Executed test runs:
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Michał Sawicz (saviq) wrote : | # |
> > I wonder if instead we should just pass availableGeometry, with Mir being
> > responsible for policy, should we involve the shell like this?
> I dislike this idea, as effectively we'd need to educate Mir about the entire
> QML scene: which areas are off-limits for a non-fullscreen surfaces, what to
> do for surfaces of different types, stages, etc. Defining a vocabulary for
> that would be a nightmare IMO. And if Mir makes a decision that shell doesn't
> like, shell will immediately impose its will anyway - so where's the gain?
I'm thinking about, for example, initial placement based on previous runs and such. Maybe Mir could (optionally?) give up a preferred position and the shell would come back with the same or changed if not possible in current setup or something. Anyway, later. The gain? More logic shared between Mir shells.
> Policy I hope to define in Mir relate more to clients expectations, I want to
> ensure that client surfaces behave in a consistent way across mir server
> implementations. Shells should treat client surfaces in ways that they expect,
> that parent/child relationship is obeyed, focus handing is correct, input is
> delivered to the correct surface, siblings can attach to eachother/their
> parent and stay there, things like that.
What you said above applies here just as well - shell, if not well behaved - can impose its own will.
| Gerry Boland (gerboland) wrote : | # |
> I'm thinking about, for example, initial placement based on previous runs and
> such. Maybe Mir could (optionally?) give up a preferred position and the shell
> would come back with the same or changed if not possible in current setup or
> something. Anyway, later. The gain? More logic shared between Mir shells.
Yeah definitely, that's something Mir can give us, including saving the positions on close so it can inform us where it should re-open.
> > Policy I hope to define in Mir relate more to clients expectations, I want
> to
> > ensure that client surfaces behave in a consistent way across mir server
> > implementations. Shells should treat client surfaces in ways that they
> expect,
> > that parent/child relationship is obeyed, focus handing is correct, input is
> > delivered to the correct surface, siblings can attach to eachother/their
> > parent and stay there, things like that.
>
> What you said above applies here just as well - shell, if not well behaved -
> can impose its own will.
Sure. It's a line we have to walk carefully, but I think it's more important to try guarantee behaviour for clients. Mir can define that policy, and look after surface position/size save/restore, but I don't want to go down the road of trying to educate Mir of everything happening in the QML scene.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:163
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Michał Sawicz (saviq) wrote : | # |
> I tried:
>
> Binding {
> target: ApplicationManager
> property: "surfaceAboutTo
> value: function surfaceSizer(
> surface.width = 400;
> if (surface.appId && surface.appId == "dialer-app") {
> surface.height = 300;
> }
> return surface;
> }
> }
>
> and got this error:
> file://
Hah! Interesting. Can't say I understand. If Binding.value is of type
other than var, how can it be flexible enough? Otherwise if
ApplicationMana
your original approach to assign instead of bind work in any case?
I'd say that's worth a QTBUG.
| Gerry Boland (gerboland) wrote : | # |
> > I tried:
> >
> > Binding {
> > target: ApplicationManager
> > property: "surfaceAboutTo
> > value: function surfaceSizer(
> > surface.width = 400;
> > if (surface.appId && surface.appId == "dialer-app") {
> > surface.height = 300;
> > }
> > return surface;
> > }
> > }
> >
> > and got this error:
> > file://
> function to a property of any type other than var.
>
> Hah! Interesting. Can't say I understand. If Binding.value is of type
> other than var, how can it be flexible enough? Otherwise if
> ApplicationMana
> your original approach to assign instead of bind work in any case?
>
> I'd say that's worth a QTBUG.
My guess is that Binding does some naive type checking, and QJSValue is indeed not a QVariant. qtdeclarative5:
I don't create a binding with my original approach, it's a simple assignment. I would guess the only way around this error is to replace QJSValue with a QVariant. What say you?
| Michał Sawicz (saviq) wrote : | # |
> My guess is that Binding does some naive type checking, and QJSValue is indeed not a QVariant. qtdeclarative5:
Yeah.
> I don't create a binding with my original approach, it's a simple assignment. I would guess the only way around this error is to replace QJSValue with a QVariant. What say you?
Doesn't sound like that would help, since you'd still need to go through
a Binding and that would complain that function is not a var.
So it looks like assignment is the only way indeed. Worth a QTBUG IMO.
If you can assign something to a property, you should be able to bind to.
| Michał Sawicz (saviq) wrote : | # |
Please rebase on lp:~dandrader/unity-api/lifecycle, no need to bump versions over that one then.
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:165
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:166
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| PS Jenkins bot (ps-jenkins) wrote : | # |
PASSED: Continuous integration, rev:170
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
Click here to trigger a rebuild:
http://
| Albert Astals Cid (aacid) wrote : | # |
Code looks good, haven't time to test. If nobody beats me to it, i'll do on Monday
| Albert Astals Cid (aacid) wrote : | # |
Let's wait for https:/
- 171. By Gerry Boland on 2015-03-24
-
Merge trunk
- 172. By Gerry Boland on 2015-03-31
-
Add unity::
shell:: application: :Globals - 173. By Gerry Boland on 2015-07-13
-
Merge trunk
- 174. By Gerry Boland on 2015-07-13
-
Merge app-focus-state branch as prereq
- 175. By Gerry Boland on 2015-07-13
-
Document the Global class
- 176. By Gerry Boland on 2015-07-13
-
Revert 175
- 177. By Gerry Boland on 2015-07-13
-
Remove old Globals idea
- 178. By Gerry Boland on 2015-07-29
-
Merge trunk
- 179. By Gerry Boland on 2015-09-03
-
Merge trunk
- 180. By Gerry Boland on 2015-09-07
-
Remove bad merge atrifacts
Unmerged revisions
- 180. By Gerry Boland on 2015-09-07
-
Remove bad merge atrifacts
- 179. By Gerry Boland on 2015-09-03
-
Merge trunk
- 178. By Gerry Boland on 2015-07-29
-
Merge trunk
- 177. By Gerry Boland on 2015-07-13
-
Remove old Globals idea
- 176. By Gerry Boland on 2015-07-13
-
Revert 175
- 175. By Gerry Boland on 2015-07-13
-
Document the Global class
- 174. By Gerry Boland on 2015-07-13
-
Merge app-focus-state branch as prereq
- 173. By Gerry Boland on 2015-07-13
-
Merge trunk
- 172. By Gerry Boland on 2015-03-31
-
Add unity::
shell:: application: :Globals - 171. By Gerry Boland on 2015-03-24
-
Merge trunk

<Saviq> greyback, wonder, could this not ba Q_PROPERTY?
Maybe it could, in which case the API would be prettier. I'll see if it works