On Mon, May 7, 2012 at 2:35 PM, <kai.koe...@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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
