[Interest] Having two QDeclerativeContexts , setSource of one through the other?

[Sivan Greenberg]

On Mon, May 7, 2012 at 2:35 PM,  <kai.koehne at nokia.com> wrote:
> Sure. You can just expose the QDeclarativeView object in the context of the controller engine. Then you'd >just need to set the 'source' property. Anyhow, you could as well use an indirection by exposing your own >reload() function to the context ...
>

Right, that's even easier I'll experiment with that to start.

> Hybrid apps can be implemented in two ways: Some of the libraries/elements the loaded .qml file uses is >implemented in C++. In this case the logic in the library should be written in a way such that it can handle the >reconstruction of the object tree (and IMO it's fair to assume that, everything else is hackish).

This is to tackle the apparent situation that whenever the new QML is
loaded, the C++ bond libs with the QML interface get wiped off memory?
In turn, necessitates reloading them by the user code, or
alternatively - Can I  save the import list off the running App UX
QDecelerativeContext  - and reload them into the context myself,
before the user's code is expecting to find them when run again after
the reload?

>The alternative is that there's a main.cpp which sets up additional context for the QDeclarativeView. I understand you mean the latter. Well, there's obviously no magic bullet here, since the C++ backend might or might not be able to handle sudden 'reloads' where e.g. the pointer to the root element gets invalid, the internal state of the whole UI resets etc.
>

This is the same as the mentioned above then, no? (this is rather
interesting aspect of the views/context, trying to sharpen my grasp of
it)

Thank you for your elaborate replies!

-Sivan