[Michael]

In the multilevelmultiscene game, navigation is handled by states and passing signals back to main.qml for handling. I have a ‘results’ scene that is moved to after the gameScene, so I was going to setup a signal resultsPressed, and have that handled in the main, but I realised it’s equally possible to call a state change in the gameScene itself, e.g.

onPressed: {
                    console.log("going to results...")
                    window.state = "results"
//                    resultsPressed()

It seems to work ok, but I wonder is it acceptable or conventional to do that so directly there, or is it better to encapsulate all that scene redirection in main (and have the signal etc)?

BTW thanks for all you and your team’s great support in the forums.

Cheers, Michael.

[AlexFelgo Team]

Hi Michael,

for bigger projects, I personally prefer to have the actual change of properties inside the file that contains the item that owns these properties, and communicate between the files mainly with methods and signals, just as if it was a class with private properties and public methods (that is possibly because I come from an object oriented programming background). It makes it the code more readable and reproducible in my opinion.

On the other hand, for simple tasks like switching the state of the main window, this could of course also be done by directly changing the property in any scene. The most important thing is consistency 😉

The reason we took the signal approach in the multiscene demo is that you can see all the possible scene changes at one spot (in the main), including the scene changes after clicking the back button.

Cheers, Alex