Using QStackedWidget for navigation
-
Very new to this - please excuse me if I'm asking foolish questions. Please feel free to post corrections/suggestions, even if they don't directly answer my question - I'd like to get up to speed quickly!
I'm putting together a UI of around 50 pages for an embedded device with constrained resources. I am under the impression that for navigating from page to page a QStackedWidget is the way to go.
Given the size of the UI, should I be creating and adding all the pages to the UI up front, passing the QStackedWidget instance to my page classes and navigating around by using the QStackedWidget::SetCurrentIndex() method (maybe making a big global enum of all my pages)?
Or is this going to waste a foolish amount of memory?
Instead should I be clearing out the QStackedWidget every time I'm at the home page and only creating/adding items to it as the user navigates down a particular route (allowing them to navigate back to the home screen)?
Or am I looking at this completely the wrong way and should be doing something else entirely?!!
Thanks for any insight!
-
It mainly depends of the limitations of your target.
Either your cpu is rather slow and therefore I would choose to create everything upfront in order to speed-up the navigation;
Or your available memory is really low and therefore you have to keep the lesser number of objects in memory.I had a similar project and went for the first solution because the responsiveness of the application was much more important than a bigger memory consumption and with 64Mo of ram it was in fact more than enough to store all my pages (about 30) in memory.
About your global enum, I would rather used the method setCurrentWidget and use the pointer to your page instance but that's a matter of choice I guess.
To keep the code clean without "extern" everywhere, I would let the class that know of all the pages (the one were your created the stackedWidget) be the navigation controller that do the switching from one page to an another and use signal and slots to let it know when it has to switch to another page but that's just the way I did it, there may be better solution ;)
Regards,
-
Hi and welcome to devnet,
Like @Zoyhar wrote, how constrained are your resources ?
What should these pages contain ?
What should your application do ? The UI is one point but you also have to take into account all the aspect like networking, etc.
-
It mainly depends of the limitations of your target.
Either your cpu is rather slow and therefore I would choose to create everything upfront in order to speed-up the navigation;
Or your available memory is really low and therefore you have to keep the lesser number of objects in memory.I had a similar project and went for the first solution because the responsiveness of the application was much more important than a bigger memory consumption and with 64Mo of ram it was in fact more than enough to store all my pages (about 30) in memory.
About your global enum, I would rather used the method setCurrentWidget and use the pointer to your page instance but that's a matter of choice I guess.
To keep the code clean without "extern" everywhere, I would let the class that know of all the pages (the one were your created the stackedWidget) be the navigation controller that do the switching from one page to an another and use signal and slots to let it know when it has to switch to another page but that's just the way I did it, there may be better solution ;)
Regards,
@Zoyhar - Thanks heaps for the advice - we aren't that constrained for RAM, I'm going to do my first implementation in the create-everything-upfront-in-a-nav-controller fashion that you suggest. Each of the pages connects to a whole bunch of signals for hardware interactions - should I be connecting & disconnecting to all these each time the page is shown/hidden? I'm assuming if I just connect at initialisation, these in memory pages will be responding to the signals constantly instead of just when they are the active page. Does that sound right to you?
Thanks!
