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

[kai.koehne at nokia.com]

> -----Original Message-----
> From: sivang at gmail.com [mailto:sivang at gmail.com] On Behalf Of ext Sivan
> Greenberg
> Sent: Saturday, May 12, 2012 4:45 PM
> To: Koehne Kai (Nokia-MP/Berlin)
> Cc: interest at qt-project.org
> Subject: Re: [Interest] Having two QDeclerativeContexts , setSource of one
> through the other?
> 
> 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?

The libs won't be unloaded AFAIK. But the objects created from the library will be deleted, and new
ones will be created.

> 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?

Not sure what you mean by 'import list' - QML_PLUGIN_PATH?
 
> >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)

In one case the .qml files load some plugins (that might be implemented in C++), and create objects from the plugins. In the other one the context of the app + backend is set up in main.cpp, and then the main.qml file is loaded ... It's about the entry point: Is your main executable defining the backend / logic, and loads QML that accesses the backend, or is the main.cpp just a generic runner (like qmlviewer/qmlscene) that loads any kind of .qml , which then again might load some C++ plugins? Both is possible.

> Thank you for your elaborate replies!

NP. A colleague of mine is actually right now looking into implementing QML 'reloading' functionality in the context of the QML Debugger: https://codereview.qt-project.org/#change,26028 , https://codereview.qt-project.org/#change,26026 .

Regards

Kai