Hi all,
first what i’m trying to do: [maybe there is another (easier) ‘design pattern’ to this, since i can’t imagine this problem didn’t arise to anyone before]
i have one single QQuickView Window which should support switching between different “root” QML Files, e.g. you got “ProjectManagement” and “Wizard”, both are loaded via setSource() und both define signals unique to them (which are emitted somewhere inside their respective qml tree)
The MainWindow (class inheriting QQuickView) has a pointer to a QObject, which offers the slots for the currently displayed qml. After loading a new root qml, the qml itself calls a slot in the mainWindow (exported via a property in the rootContext) and requests a certain slotProvider. The mainWindow itself is ‘agnostic’ regarding to the qml it is displaying, it just knows about all possible slotProviders which are stored in a map with string keys. The mainWindow (or SlotManager as i called it in the code) disconnects the previous slotProvider and asks the new one to connect his stuff to the signals. So the sequence in short:
0 – SlotManager creates N QObjects offering slots (SlotProvider), stored in QMap<QString, QObject*>
1 – qml is loaded and does e.g. Component.onCompleted: { SlotManager.setSlotProvider(‘mainMenu’) }
2 – SlotManager sets currentSlotProvider to the correct pointer from his map and calls a method inside
the provider which connects his slots to the signals, the latter are defined in the root element of the qml
(3 – qml could request a new root element, which in turn request a new slotProvider and disonnects the old one)
So far the design part, maybe this could be done even better/nicer, basically i just need dynamic slots which are requested from the qml side. And thoses slots need to be C++ (at least partial) to offer some low-level stuff qml can’t provide.
Now the problem: in order to connect the slots i need a valid QQuickView.rootObject(), because thats the Object which emits the signals, but it seems i can’t track the moment this gets non-null from qml. This is what i’ve tried so far:
1- using Component.onCompleted (inside qml), calls a slot in the exported C++ Object which just prints the pointer, which is null at this moment (as far as i have googled on this, onCompleted gets called after parsing is done, so this won’t guarantee a valid pointer?)
2 – using onStatusChanged() (in qml), still null
3 – using onStatusChanged in cpp, (with Status = Ready) not null
4 – checking the pointer just after the setSource call in cpp, not null
Now i could of course do it from cpp side by enforcing a common interface function in qml, so the cpp side actively requests the required slot provider, as in:
setSource(“SomeThing.qml”);
invokeMethod( rootObject(), “getProvider” );
but i’d like to avoid having such an interface, because the qml side should be the one which starts the whole process.
Or maybe Qt already offers something for this, i just haven’t found it yet?
Any hints are appreciated! :)
↧