[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: Monday, May 07, 2012 11:08 AM
> To: Koehne Kai (Nokia-MP/Berlin)
> Cc: interest at qt-project.org
> Subject: Re: [Interest] Having two QDeclerativeContexts , setSource of one
> through the other?
> 
> Hello Kai, thanks for the reply.
> 
> On Mon, May 7, 2012 at 11:33 AM,  <kai.koehne at nokia.com> wrote:
> > If I got your description right you're talking about two different UI's, where
> one sets parameters to the other. I'd try to keep the two >things decoupled
> from the QML perspective, and rather have a clean interface (in C++) that
> separates it. Whether you write your >controller then in QML or QWidgets is
> up to you, but independent from the interaction with the rest... It's possible to
> interlink >QDeclarativeContexts via e.g. the context chain, but I don't see how
> that helps you ...
> 
> For starters, I just want to be able to set the source of the QML (from file/
> network) on for the controlled UI.  
>
> I then want the controlled UI to refresh
> itself with the logic and contents of the new UX (effectively allowing me to
> change version of the UI in runtime).

That's just calling QDeclarativeView::setSourceFile(), maybe with a QDeclarativeEngine::clearComponentCache upfront.

> The easiest way as I see atm is by exposing a QDeclerativeView as a QML
> element. Is that possible at all, preferably without using context to maintain
> higher level of decoupling?

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

> Other than that there's still the question- what happens with C++/ QML hybrid
> apps that expose data through contexts to the view- how to keep that intact
> for the user's code, although there should be no issue if I provide a function
> to add the controlling UI and the developer just calls it on his QApplication or
> QDeclarativeView instances.

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).  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. 

Regards

Kai

> -Sivan