QStackedWidget as 'window management' for embedded eglfs device?
-
G'day,
I've got PyQt5 built and running my application nicely with the eglfs platform. The main/home window is hardware accelerated, and refreshes at the required 60Hz. When I click a button which opens a different window however, eglfs appears to cease and the new window falls back on software rendering. Some research has suggested that eglfs doesn't support more than a single window, and that Wayland may be a better option.
First question: in terms of graphics performance and hardware acceleration, would I better off replacing my eglfs platform with Wayland and retaining my current windowed approach, or is eglfs a better performing platform than Wayland (assuming a single window application)?
Second question: if eglfs is better performing than Wayland, can I use QStackedWidgets to mimic my current multi-window approach? I.e. each window is now a widget, and I change which of the stacked widgets is displayed, as if I've opened a new window? From my understanding of QStackedWidget(), this is more or less the intent of this class, but I just want to confirm this understanding and approach before delving into my code.
-
Hi,
If you need window management then indeed, the QtWayland Compositor is likely the way to go.
As for QStackedWidget, well, it sounds like an interesting alternative especially if all your widgets are full screen.
-
Thanks @SGaist. All widgets are indeed fullscreen. I had a play around last night with implementing a QStackedWidget approach, which wasn't particularly successful. I'll do some further reading on the QtWayland Compositor today, and might rebuild Qt, PyQt5, etc. over the weekend with QtWayland.
-
Bit of an update :)
I've implemented a QStackedLayout approach, whereby I have a MainWindow, with multiple pages within a QStackedLayout, so I can essentially mimic a multi-windowed application using pages within a single window application.
So far it's working ok, but for some reason I'm unable to access variables from Page 1 on Page 2, even though they're within the same class?! I've got some more investigating to do, but given that I've consolidated 5+ .py UI files into a single .py UI file, and 5+ classes in the main .py file into a single class, I figured variable scope would be the simplest part of the entire conversion!
-
What kind of data are you passing back and forth ?
-
In this particular example it's as simple as setting a flag.
self.Flag = True ... if self.Flag == True: print("True") else: print("False")When I click on a button on Page 1, it sets the self.Flag value to True. Then when the recursive function runs in the background, while displaying Page 2, it continually prints False (as an example). It's odd because all pages are within the same class, as mentioned above.
-
Never mind me, it looks like I had accidentally 'returned' the underlying function; I must have changed some code when converting from the multi-window to single-window approach.
EDIT: I spoke too soon. I just ran an archived version of the multi-window application, which executes perfectly. The setting of the flags hasn't changed, but it looks like calling the .setCurrentIndex() function is stopping the execution of the background function.
-
It looks like you are trying to create something similar to QWizard::setField, isn't it ?
-
Not quite @SGaist, but not too dissimilar.
In short, I have a background function which runs multiple times a second to update the GUI elements on the screen (QWidgets, QLabels, QPixmaps, etc.). On the old version of the application, I could open a new window (Window.show()) and this function would continue to operate. Now that I've changed to QStackedLayout, this background function ceases when I call .setCurrentIndex(x) to change the window shown. I'm going through the code step-by-step at the moment, but I've set some print() commands at the key points in the application and it certainly appears that the .setCurrentIndex() is stopping the function.
-
I think I've found the culprit. On my multi-window version of the application, the updating of all GUI elements was driven by a paintEvent on the main QWidget, which is only on the main window. When I .show() a new window on top of the main window, calling .update() on this QWidget worked, and allowed for the updating of all QWidget, QLabels, etc., even if they were on a different window.
On the QStackedLayout application however, calling .update() doesn't work if the .currentIndex of the QStackedLayout doesn't have this main QWidget! So I'm calling .update() when changing between pages of the application, but the paintEvent() is only run when the .currentIndex() is on the main page.
-
I've separated the .painEvent() from the updating of the GUI elements on the other pages, and used a custom signal to paint the elements on the non-main page when .setCurrentIndex() is called. It's a bit of a workaround, but I'm much more comfortable now that I can tailor the updating of the separate page's GUI elements independent of the main page's main QWidget.
-
The paint event is not meant to trigger updates somewhere else.
What kind of update were you triggering and why in the paint event ?
-
Widget painting can happen for several reasons. For example because you are moving it, because you are moving something else on top of your application etc. Usually it won't happen only once.
-
I understand and agree, I was using the .update() call to force the paintEvent() and then change the colour/text of the other QWidgets/QLabels at the same time. It's all working nicely now that I've separated the paintEvent() from the GUI updating of the non-Main page QWidgets and QLabels :)
-
Great !
In that case, since you have everything working, please mark the thread as solved using the "Topic Tools" button so that other forum users may know a solution has been found :)
