As with containment, make sure Containment::applets()
is always sorted by id, to have the least sursprises possible
it adds a test
Change-Id: Ib1aeeff7c70bb6969b32b2fef8557889a43edf09
the order in which containments were restored used to be quite random:
ensure that's ordered by id this makes the shell startups be more reproduceable
from one to another, if a new containment arrives, ensure it's inserted
maintaining id order
containment::appelts() will need the same treatment
adds a test as well that checks the order is right
Change-Id: Ie1b278e5b83d7e3645f7293bf6d030aa7f43a221
if a containment's lastScreen is not -1 (and a valid screen)
*and* its activity() is not the current one, its QML
will *not* be loaded, therefore it would dangle blocking
corona::startupCompleted until the activity is selected
Change-Id: I6757d29240a012377e9ff0a22fe16541ea712ee6
Containments with no applets will emit uiReady now
It adds a test as well that checks if this is the case.
There is still a case where the corona doesn't emit startupCompleted()
that's when there is more than one activity, but that, as well the test
will be adressed by another patch on a different part.
Change-Id: I4d83aa612c29fb0f441d11681bc5aba241370bc3
consider a loaded package valid even if !isvalid() but does have some file
that indicates it has a valid packagestructure.
for how packages are loaded now, a package is never valid at first if has a required file:
because the path gets set only after the package is loaded
this fixes wallpaper loading
reintroduces an api call from plasma1:
its the only way to solve
https://bugs.kde.org/show_bug.cgi?id=337200
basically to avoid a crash when plasma starts with missing containments in the appletsrc and a locked corona, or a screen added with locked widgets.
it's the only entry point that allows a creation of a containment when widgets are locked
REVIEW:119513
CCBUG:337200
