Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Switching between different screens



  • I have a QML Fullscreen application running on a raspberry with a touch-display. First I display a welcome page which is in its own qml file WelcomeScreen.qml, with buttons which should switch to a SettingsScreen.qml or a FileViewScreen.qml

    I wonder what the best way is to switch between those screens. E.g. if I want to display the FileViewScreen.qml, I should set it to visible and probably disable the currently displayed qml file via setting its visibility to false.

    Right now, I do this in my main.qml with a function:

    property var screenList: [welcomeScreen, settingsScreen, fileViewScreen]
    
    function setScreenVisible(screen) {
      var s;
      for(s in screenList) {
        screenList[s].visible=false
        screenList[s].enabled=false
      }
      screen.visible=true
      screen.enabled=true
    }
    WelcomeScreen{
      id: welcomeScreen
    }
    SettingsScreen{
      id: settingsScreen
    }
    FileViewScreen{
      id: fileViewScreen
    }
    

    Can I somehow use this setScreen function from c++? I could call it with a signal but would not know what the argument should be. Or is there a better way to do it?

    In principle, all I want to achieve is that I can switch between WelcomeScreen, SettingsScreen and FileViewScreen.





  • @6thC I fear my question was not phrased very well. I edited it.



  • Hi @maxwell31. I recommend you that do not include c++ in this logic. Use c++ for back-end task and manage complex data, receive data, if that is your case for example.

    Manage your screen, is an important task. You must ensure that all the visual components that you are using in the "initial screen", must be loaded on demand. The same behavior about your screens. The same issue I encountered when I began with Qt Quick. I have many charts on one screen, and on the other, I have a 3d scene. I only use a StackLayout to control the visible property, but the two screens ran at the same time, and this was a bad performance practice.

    I suggested creating components dynamically. Check this link http://doc.qt.io/qt-5/qtqml-javascript-dynamicobjectcreation.html. Check the StackView component http://doc.qt.io/qt-5/qml-qtquick-controls-stackview.html.

    Good luck.



  • Thank you for your comment. I thought about doing things dynamically. However, the screens are rather simple, and I wonder if dynamically loading them would not be detrimental to performance.

    One thing is, that the app might communicate with an embedded device, so the backend will handle the communication with the device. It will be necessary, that if the embedded device finishes some operation, the GUI state changes. This is why I thought about doing it directly from c++, but I guess using a signal would be as good.



  • The dynamical loading of components works perfectly. The advantage is that you control the creation and destruction of the object, so no bad performance issue its achieved with this approach, on the contrary. See this if you have doubts yet please read this http://doc.qt.io/qt-5/qtquick-performance.html.

    I use the same architecture. So, the solution is the signal/slot mechanism. So, in case that your GUI does not block, use the WorkerScript component http://doc.qt.io/qt-5/qml-workerscript.html.

    Good luck, @maxwell31.



  • Yup. I'd just note, I don't use component.createObject - I use incubators
    http://doc.qt.io/qt-5/qml-qtqml-component.html#incubateObject-method

    If you have issues and want to use many incubator I might be able to help as I ran into some as I hit it with many at once - I ended up having to remember pending incubations in an object and remove them (from the pending container) once completed/loaded.

    For adhoc the example seems ok. I just found multiple simultaneous and javascript scoping would tread on each other. Or something, I needed to go to support to get that resolved but I have it working great for me now. Really cool to not have any gui lockups at all...


Log in to reply