Idea: making .ui files recursive
I just wanted to pitch an idea here. I put it into tools, because it is basically about QDesigner.
Sometimes, you want to use a specific constellation of widgets in more than one place. You can of course in such a case make widget out of that, and then either use widget promotion or even create a Designer plugin for it. However, those methods are not always convenient:
- When using promotion, you can not actually see the result, and things like size policies are most likely off.
- In order to use a plugin, you need to do quite a bit of additional work.
It would be nice if you would be able to basically include an existing .ui file in another .ui file. That would make it easy to make composites of existing components.
A potential issue are clashes that may occur between names of components in the .ui file, or when you insert the same .ui file twice. Multiple solutions are possible. One solution could be to prepend the name with a group name, but I think i would prefer to actually generate embedded structs for each of the included .ui files, and create an instance of that struct under the name of the group itself. What I have in mind is that, when you insert a .ui file, you give it a name just like any widget that you add. Normally, all widgets are accessible from code as something like this:
- m_ui.lineEdit1->setText("Use a better name for your components please!");
For widgets inside an inserted .ui file, this could become:
Only a header file for the directly used .ui file would be generated by uic, and that one would contain everything needed to create all the widgets in the layout, including the widgets inside the embedded .ui files. The declaration might look something like this then:
This would allow you to further componentize your .ui designs without requiring the creation of plugins, and without the limitation of not seeing what you are doing.
Comments? Would such a thing be feasable? Would it be useful?
I think actually embedding the componentx.ui in componenty.ui would not be a good thing. You need to duplicate knowledge about internal behavior for proper operation.
An alternative would be a reference to a widget, which is pretty much done by promotion right now. Possibly the relevant ui (if any) could be added to the containing ui as a reference for the designer — it is not used during actual code generation, but it is used when using the designer. Maybe a basic plug-in like thingy could be created for this behavior?
For hand-coded widgets, one would still need the plug-in.