Hello Kai, thanks for the reply. On Mon, May 7, 2012 at 11:33 AM, <[email protected]> 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). 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? 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. -Sivan _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
