0

I appologize for the long paragraph but its the only way I can explain this.

Basic Question: How do I have multiple windows that share some UI functionality without having it all in one giant class?

My Situation: I have a question regarding the Design of an application containing multiple windows. The windows will share several of the components on the UI (date & time, battery, etc.). Each window will also have much of its own ui functionality. My original idea was to have separate windows so that the class was not so large and the ui files were easier to look at. However, I find that I have repeated code for the shared ui functionality since I have to implement it in each class. Also, I am forced to have many connections between windows to make sure certain things are handled when changing windows.

Possible Solution: I have read that a QStackedWidget is good for multiple windows, but everything will be in one class. Unless of course there is a way of handling some of the ui in a subclass of the main ui? Without making other ui files?

1 Answers1

1

I agree with using a QStackedWidget. I generally design my applications with the following ideologies:

  1. Each window/screen has its own class.
  2. If there is repetition of functionality or code, that part gets its own class (which is inherited by each of the window classes).
  3. QStackedWidget implementation is written in the first class for which main.cpp instantiates the object and shows.
  4. To prevent high memory usage, I implement the class containing the QStackedWidget to dynamically create the window classes and delete them (as required). This is optional and will be based on your application's performance on your device.
Aditya
  • 439
  • 4
  • 14
  • Would I be able to design the dynamic classes (the widgets in the stackwidget) in the ui? Or would I only be able to design in main.cpp, because that is where the ui is? –  Jan 26 '18 at 18:18
  • I realize I can make a class and add it to the stacked widget, but then I will have to design the interface in that class with code, correct? –  Jan 26 '18 at 18:19
  • What I mean by 'dynamically` is to actually allocate the object when accessing and destroying as soon as you go to another screen. If you want to do this, you need proper control and it is thus better to actually program this behavious instead of a drag and drop inside the ui. – Aditya Jan 26 '18 at 18:24
  • Also, the `.ui` file doesn't belong to `main.cpp`. It is used in the generation of `ui_.h`. The class uses this header file to show your design. Notice the `ui->setupUi(this)` in the constructor. – Aditya Jan 26 '18 at 18:33
  • 1
    If I am dynamically allocating and then deleting when I go to another screen, then why have a QStackedWidget? If only one widget can be active at once, why not just have a widget on the ui that will become whichever widget is dynamically allocated? I know a qstackedwidget is for holding multiple windows, but in this case only one window exists at a time (besides the control window) –  Jan 26 '18 at 18:44
  • Also, yes i understand the ui belongs to class, not the main. I didn't mean to say that. –  Jan 26 '18 at 18:44
  • You can have it either way (allocate/deallocate or not). In this particular idea, I use `QStackedWidget` purely as a handler. I feel it is easier to handle it that way because sometimes a widget or two would stay common for all screens (like a status bar widget). – Aditya Jan 26 '18 at 18:48
  • But yes, if you want all widgets to stay active at all times, you can do that. I do try to minimize memory requirement since I majorly develop on embedded devices - hence this approach. – Aditya Jan 26 '18 at 18:48
  • This is what I would call a `Dynamic Tiered Approach`. I have 1 main screen active at all times. The secondary screen(s) like settings screen and info screen need not be active at all times - I would use the dynamic idea for the secondaries and not the main screens. – Aditya Jan 26 '18 at 18:55
  • I agree that i should have my main screen and then dynamically allocate the other windows when needed. I have a top bar (like a status bar) that all windows will share. I can only have one window at a time. The main screen will be the screen with the bar. I am still confused how a QStackeWidget will be of any use if we will only have one "secondary" window at a time. Add it to the stacked widget and then remove when the screen is changed? That would mean only one window is in the stacked widget at a time. –  Jan 26 '18 at 19:06
  • Yes, you will have have one secondary screen at a time (and further levels if that secndry screen has more depth) in this approach. Not sure what you are concerned about here. – Aditya Jan 26 '18 at 19:11
  • Move the status bar into a separate `QWidget` class and place it above the `QStackedWidget` in your main class if you can. That way you dont have to mess with it again. – Aditya Jan 26 '18 at 19:14
  • Class main window has stackedWidget. Window1 is added to stacked widget. Window1 has button in its class that creates dynamic Window1_level1. So, main window needs a connection to window1 to know when to add a further level to its stacked widget? Is that what you are thinking? –  Jan 26 '18 at 19:47