Unsolved How to stucture fullscreen Raspberry Pi application with screen transitions?
I am a Qt Newbie. I am trying to create a PyQt5 application for Raspberry Pi screen in fullscreen mode. The application is meant to behave in a similar fashion as a mobile application. It will have several screens, which appear based on user interaction with buttons/inputs. I would like to ask for guidance on how I should structure the application in PyQt5 from a high-level point of view.
Here is what I would like to achieve:
As you can see, the application has several screens which appear and disappear based on pressed buttons with slide transitions. I am looking for ideas on how to structure the application. Namely, how should each screen be created? Should each screen be a separate Window? Perhaps each screen should be a separate Layout within one window, in which case a given layout would appear based on the button pressed? Should all screens be initiated at startup or when a given button is pressed? Also, how should I handle transitions between screens?
For now, I have initiated the initial screen with the two buttons as a custom Window inheriting from QWidget. When a given button is pressed, I create a QAnimation object for each button and send those buttons off-screen. However, I do not know how to replace those two buttons with the given screen. Should I initiate the appropriate buttons outside of the screen and then create animations to bring them to their proper positions within the screen? Or, perhaps, create a new Window with the appropriate buttons initially outside of the screen boundaries and then animate those buttons to come to their correct positions? As you can see, I am confused about the structure of the entire application. As such, I am looking for any input regarding how to achieve the same as in the above video.
Any thoughts are deeply appreciated. Thank you.
Have you looked into QML
In your use case, it might fit better than desktop widgets.
@mrjj Thank you. Following your advice, I looked into Qml and I admit it that, using StackView, one might achieve transitions easily. However, I originally forgot to add that the application will neither have a touch screen nor a mouse. In fact, it will be controlled by several hardware buttons, such as keyUP, keyDown, keyRight, keyLeft, btnAccept, etc... It seems to me that QtQuick is perfect for the scenario in which there is a touch screen or a mouse available - scrollable Views, drawers, check boxes etc. fit perfectly then. However, due to the control limitations I am facing, the flow will be the following:
the user will navigate between buttons on the screen by pressing left, right, up and down to hover over a given button and then press the accept button to simulate the button press. In that scenario, it seems to me that many of the functionalities that QML provides are not used. For instance, a scrollable list view cannot be incorporated since it depends on scrolling motion, which cannot be done using the hardware buttons that I will implement.
Do you think that my concerns are legitimate or would you still continue with QML? Thank you!
- Do you think that my concerns are legitimate or would you still continue with QML? Thank you!
Yes its a valid concern as QML is really aimed at having a pointing device of sorts. ( incl fingers)
But im not sure it will pose a bigger/harder problem than desktop widgets will give you since
those are not optimized for keyboard only operation either. ( having a tab key helps ;)
Also since its so possible to mix QML with c++, you could read the hardware keys from c++ and map into signals
for menu up , menu down and menu activate. So i still think it can work but I have never tried something like that
We can ask for advice
Hi @Wieland , do you know if its extra hard in QML to have special keyboard handling?
Hi! I agree with @mrjj that using QtQuick for implementing a fancy GUI is the best way. Also I don't see any real problem in controlling the GUI with a special input device. As @mrjj already pointed out you can implement the keyboard handling in C++. My first idea would be to have a single QObject for this. Everytime a key is pressed this object would emit a Qt signal. You can then add this object to the QML context as a context property. The QtQuick objects can then react to the signals in any way you want.