Merge lp://staging/~nick-dedekind/unity8/sidestage-restoreOnRotation into lp://staging/unity8

FAILED: Continuous integration, rev:2393
https://unity8-jenkins.ubuntu.com/job/lp-unity8-ci/1280/
Executed test runs:
    FAILURE: https://unity8-jenkins.ubuntu.com/job/build-0-fetch/1722/console

Click here to trigger a rebuild:
https://unity8-jenkins.ubuntu.com/job/lp-unity8-ci/1280/rebuild

Nice refactoring in tst_TabletStage.

-----------

This sure is the easiest way to fix that bug, but I think it's wasteful to keep updating a database on disk (IO) about information you already keep in a variable in RAM. You only need to write that info to disk once the application goes away, as you are no longer keeping tabs on it in RAM.

Why does it lose that information when you rotate the shell?

What will happen if an application has two surfaces (one in main and one in side stage) and you rotate to portrait and then back to landscape (tst_OrientedShell doesn't have yet those app list controls so I could easily reproduce this use case)?

FAILED: Continuous integration, rev:2393
https://unity8-jenkins.ubuntu.com/job/lp-unity8-ci/1288/
Executed test runs:
    FAILURE: https://unity8-jenkins.ubuntu.com/job/build-0-fetch/1731/console

Click here to trigger a rebuild:
https://unity8-jenkins.ubuntu.com/job/lp-unity8-ci/1288/rebuild

Text conflict in qml/Stages/SurfaceContainer.qml

> Nice refactoring in tst_TabletStage.
>
> -----------
>
> This sure is the easiest way to fix that bug, but I think it's wasteful to
> keep updating a database on disk (IO) about information you already keep in a
> variable in RAM. You only need to write that info to disk once the application
> goes away, as you are no longer keeping tabs on it in RAM.

This is really a performance problem with the WindowStateStorage component.
We could make it batch state changes, or only save to disk out on exit; but that's for a different MP.

>
> Why does it lose that information when you rotate the shell?

When we rotate to and from portrait, the sidestage enables/disables (because sidestage not available in portrait). This triggers a refresh of the last saved stage (ie the last one due to user interaction [ie. dragging or closing]).

1) First open app.
   - MainStage loaded as default.
2) Drag app to SideStage.
   - state saved to SideStage.
3) Rotate device to portrait
   - App switches to MainStage because that's all that is available
4) Rotate device back to landscape
   - Reload saved stage = SideStage.

So if we drop on SideStage, then flip to portrait it will load in MainStage because SideStage is not available, but flip back to landscape and it will reload the last dropped stage (SideStage)

>
> What will happen if an application has two surfaces (one in main and one in
> side stage) and you rotate to portrait and then back to landscape
> (tst_OrientedShell doesn't have yet those app list controls so I could easily
> reproduce this use case)?

We'll have to have stage saved/loaded per surface. For another MP.

> Text conflict in qml/Stages/SurfaceContainer.qml

From prereq. fixed.

> > Nice refactoring in tst_TabletStage.
> >
> > -----------
> >
> > This sure is the easiest way to fix that bug, but I think it's wasteful to
> > keep updating a database on disk (IO) about information you already keep in
> a
> > variable in RAM. You only need to write that info to disk once the
> application
> > goes away, as you are no longer keeping tabs on it in RAM.
>
> This is really a performance problem with the WindowStateStorage component.
> We could make it batch state changes, or only save to disk out on exit; but
> that's for a different MP.
>
> >
> > Why does it lose that information when you rotate the shell?
>
> When we rotate to and from portrait, the sidestage enables/disables (because
> sidestage not available in portrait). This triggers a refresh of the last
> saved stage (ie the last one due to user interaction [ie. dragging or
> closing]).

Actually, it probably shouldn't save out on close. Will have to look into that...

>
> 1) First open app.
> - MainStage loaded as default.
> 2) Drag app to SideStage.
> - state saved to SideStage.
> 3) Rotate device to portrait
> - App switches to MainStage because that's all that is available
> 4) Rotate device back to landscape
> - Reload saved stage = SideStage.
>
> So if we drop on SideStage, then flip to portrait it will load in MainStage
> because SideStage is not available, but flip back to landscape and it will
> reload the last dropped stage (SideStage)
>
> >
> > What will happen if an application has two surfaces (one in main and one in
> > side stage) and you rotate to portrait and then back to landscape
> > (tst_OrientedShell doesn't have yet those app list controls so I could
> easily
> > reproduce this use case)?
>
> We'll have to have stage saved/loaded per surface. For another MP.

FAILED: Continuous integration, rev:2394
https://unity8-jenkins.ubuntu.com/job/lp-unity8-ci/1499/
Executed test runs:
    FAILURE: https://unity8-jenkins.ubuntu.com/job/build/1998/console
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-0-fetch/2026
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-1-sourcepkg/release=vivid+overlay/1943
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-1-sourcepkg/release=xenial+overlay/1943
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-1-sourcepkg/release=yakkety/1943
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=amd64,release=vivid+overlay/1934
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=amd64,release=vivid+overlay/1934/artifact/output/*zip*/output.zip
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=amd64,release=xenial+overlay/1934
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=amd64,release=xenial+overlay/1934/artifact/output/*zip*/output.zip
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=amd64,release=yakkety/1934
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=amd64,release=yakkety/1934/artifact/output/*zip*/output.zip
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=armhf,release=vivid+overlay/1934
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=armhf,release=vivid+overlay/1934/artifact/output/*zip*/output.zip
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=armhf,release=xenial+overlay/1934
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=armhf,release=xenial+overlay/1934/artifact/output/*zip*/output.zip
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=armhf,release=yakkety/1934
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=armhf,release=yakkety/1934/artifact/output/*zip*/output.zip
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=i386,release=vivid+overlay/1934
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=i386,release=vivid+overlay/1934/artifact/output/*zip*/output.zip
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=i386,release=xenial+overlay/1934
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=i386,release=xenial+overlay/1934/artifact/output/*zip*/output.zip
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=i386,release=yakkety/1934
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=i386,release=yakkety/1934/artifact/output/*zip*/output.zip

Click here to trigger a rebuild:
https://unity8-jenkins.ubuntu.com/job/lp-unity8-ci/1499/rebuild

FAILED: Continuous integration, rev:2396
https://unity8-jenkins.ubuntu.com/job/lp-unity8-ci/1502/
Executed test runs:
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build/2002
    UNSTABLE: https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/label=amd64,release=vivid+overlay,testname=qmluitests.sh/1016
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/label=amd64,release=xenial+overlay,testname=qmluitests.sh/1016
    UNSTABLE: https://unity8-jenkins.ubuntu.com/job/test-0-autopkgtest/label=amd64,release=yakkety,testname=qmluitests.sh/1016
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-0-fetch/2030
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-1-sourcepkg/release=vivid+overlay/1947
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-1-sourcepkg/release=xenial+overlay/1947
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-1-sourcepkg/release=yakkety/1947
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=amd64,release=vivid+overlay/1938
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=amd64,release=vivid+overlay/1938/artifact/output/*zip*/output.zip
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=amd64,release=xenial+overlay/1938
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=amd64,release=xenial+overlay/1938/artifact/output/*zip*/output.zip
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=amd64,release=yakkety/1938
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=amd64,release=yakkety/1938/artifact/output/*zip*/output.zip
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=armhf,release=vivid+overlay/1938
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=armhf,release=vivid+overlay/1938/artifact/output/*zip*/output.zip
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=armhf,release=xenial+overlay/1938
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=armhf,release=xenial+overlay/1938/artifact/output/*zip*/output.zip
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=armhf,release=yakkety/1938
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=armhf,release=yakkety/1938/artifact/output/*zip*/output.zip
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=i386,release=vivid+overlay/1938
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=i386,release=vivid+overlay/1938/artifact/output/*zip*/output.zip
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=i386,release=xenial+overlay/1938
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=i386,release=xenial+overlay/1938/artifact/output/*zip*/output.zip
    SUCCESS: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=i386,release=yakkety/1938
        deb: https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=i386,release=yakkety/1938/artifact/output/*zip*/output.zip

Click here to trigger a rebuild:
https://unity8-jenkins.ubuntu.com/job/lp-unity8-ci/1502/rebuild

So spreadDelegate.stage means stage where the surface currently is in, whereas you use WindowStateStorage for holding the stage where the *user* wants the surface to be in (preferred/selected stage).

That's misuse of WindowStateStorage.

It's like you saving the surface geometry into WindowStateStorage on every single window resize.

The purpose of WindowStateStorage is to store the last window state right before it's gone. So that when this application is launched again (seconds, minutes, months or years later), its window starts with the same state that it had when it was last used.

> So spreadDelegate.stage means stage where the surface currently is in, whereas
> you use WindowStateStorage for holding the stage where the *user* wants the
> surface to be in (preferred/selected stage).
>
> That's misuse of WindowStateStorage.
>
> It's like you saving the surface geometry into WindowStateStorage on every
> single window resize.
>
> The purpose of WindowStateStorage is to store the last window state right
> before it's gone. So that when this application is launched again (seconds,
> minutes, months or years later), its window starts with the same state that it
> had when it was last used.

No, it's called "window state storage". It's storing whatever state you want it to store(last/preferred).
The fact that we use it to store the last position/geometry is a implementation decision of that use case.

And this is preserving the last "valid" state anyway.
If we save it on exit when in portrait and load it again in landscape we will end up in a state different to when we exited the app.

I'm with nick on this one. It's ok to use WindowStateStorage as a storage during runtime too. If the syncing to disk is the issue here (which I'm not really sure if it is, because it's not that we're hitting the flash really often) then yes, the WindowStateStorage component should be changed to only sync later or something. I however would probably vote to sync all the time because this way it saves the user's preferences even when something crashes.