How to stucture fullscreen Raspberry Pi application with screen transitions?

[dgb589]

Hello,

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:

https://www.youtube.com/watch?v=0U0faMYDbCg

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.

[anda_skoa]

My overall suggestion would be to go for QtQuick (QML) for this type of interface.

Transitions like that are easy to do with QtQuick animations but a lot of work with widgets.

Each screen can then be done as a separate QML obejct/file, transitions could potenially be delegated to a StackView.

Cheers,
_

[dgb589]

@anda_skoa 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!

[anda_skoa]

While the components are touch aware, I don't see any problem when not using that.

E.g. you can scroll the listview programmatically, on press of a button, keyboard key, hardware button or dial.

A lot of the QtQuick based HMIs for cars, machine control interfaces, etc., use hardware controls as input devices, some exclusively, some in addition to touch screen capability.

Cheers,
_