How to make a good architecture for promoted widgets?

[Saviz]

I have an application that consists of many promoted widgets. Most of these promoted widgets function just fine following the single responsibility pattern. They do their own work and do not need anything from the outside world.

However, some of these widgets are responsible for tasks that can effect others. This includes the Settings pane that is responsible for holding and changing the settings that the entire application uses. Therefore, I have a couple of questions that I wanted to ask:

1- Is this approach even feasible or valid?

(What I mean is, I can just as well have one huge QMainWindow that stores everything and does all the functionality. The reason why I even attempted to separate my program into multiple promoted widgets in the first place is because how easy it makes to maintain it. But, now I am wondering if what I am doing is wrong as it creates a ton of issues such as: difficulties in communication between other parts, massive increase in code size, etc...)

2- Is there any way to manipulate and control when a promoted widget gets created and initialized?

(As far as I can tell, promoted widgets are created and initialized at run time. I was wondering if there is any way to tell the designer which one of them gets created first. This is because as I mentioned before some of them need to be present before others. Because they provide others with some key information such: providing file paths, volume settings, theme settings and etc...)

3- Is there a way to add these promoted widgets at compile time instead of run time?

(If this is possible, then is it recommended?)

Thank you for taking the time to read and answer my questions.

[Chris Kawa]

@Saviz I think the problem here is not exactly with promoting, but with your app structure. Widgets are display objects. They are not exactly meant to be used as data stores. If you have some global settings create a non-visual settings object. When a widget is crated initialize it with that object pointer or reference. If the widgets should reflect the changes in the settings make it emit a change signal and connect it to the widgets so that they update. that way the order of creation of widgets doesn't matter. You can initialize settings object before any UI exists.

To address your questions directly:

1- Is this approach even feasible or valid?

I don't exactly see how using promoted widgets would increase code size, but there's nothing wrong with using them in general.

2- Is there any way to manipulate and control when a promoted widget gets created and initialized?

All UI placed in the designer is created in the setupUi() function. The order of creating widgets is unspecified. If you need to control the order you can always just create the widgets from code and add them to appropriate layouts after the setupUi call. But again, from what you describe you just structured your app badly and use visual elements to store data. If you extract the data portions from the widgets into appropriate objects the order of creation won't matter.

3- Is there a way to add these promoted widgets at compile time instead of run time?

What does that mean? A widget is created by a call to new SomeWidgetClass(). How would calling a dynamic allocation when compiling it on your machine create an object later on my computer when I run the app? No, that's not how it works.
When you put a widget in a designer the uic tool translates that to a call to constructor and puts it in the generated setupUi() function. You can look inside the generated function if you want to see what it does.
If you don't want a widget to be created for you automatically then don't put it in the designer. Create it manually in your code when you need it.

[Saviz]

@Chris-Kawa Thanks for the reply. Can you please send me a link to an article that will help me to make better structures as well as showing me how to implement a good settings architecture for my app?

[Chris Kawa]

@Saviz Sorry, I don't know such article. But basically create a settings object and store the settings in it instead of in widgets classes.