QT Designer? Coding by hand?

[Kumosan]

The problem is QButtonGroup doesn't change the parent-child relation, meaning that you can have buttons with different parents inside a single button group. So I don't see a way of "dropping" buttons on the button group - you couldn't drop them on a button group AND parent widget at the same time.

Ok, this is a weak point in my idea. However, in all my years of development with Qt, it never ever had a QButtonGroup with buttons with different parents.

Actually... I'd argue with that. Qt4 Designer is meant to be strictly a layout editor.

Perhaps because noone seriously though about it how to improve it and to make it better beyond pure layout design?

Are the "meta-objects" you refer to related to QMetaObject? If not, please try to use a different name as we may be confusing each other here...

Not in code, but in the idea. But you are right, let's define:

With a QDesigerObject I mean an object, which can be created by generated code from the designer, which contains a part of the user interface hierarchy.

With QDesignerMetaObject I mean an Object, which is located within a QDesignerObject, which might carry additional informations for all objects (references/pointers) within this QDesignerObject.

In general it applies to all things you actually do. I tend to assume some sanity of the developer doing the job. If you make a typo, you'll widget will not make it into the button group. This is really easy to track.

I don't think I can agree here. Of course you are right that it applies to all things we do, and that bugs can be found. But if the compiler or some tool can help prevent bugs like that in the first place, it should be used.

Again, qFindChild() does that...

But this is only a small part of what I want. And it handles a concrete object. My idea was not to find a concrete child, but a certain node in a tree.

So you'd like to maintain a virtually unlimited trees of object hierarchies indexed by names, right? So you'd like to have parent-child relations simmilar to the ones maintained by QObject and it's parent-child relation indexed by objectName property, correct? This is fine with me, although I believe it would increase resource usage and object deletion time significantly.

I am not sure about that. The QDesignerObject tree, which, according to my proposal, in the designer should be created like a layout tree, would have to be kept in the resources. Temporarily an at best medium sized xml structure. This information is only needed to build the QDesignerObjects. Once the gui is created, this info could be unloaded/deleted. I would have a small influence on the gui creation, but none on object deletion.

But I don't see why Designer should handle such grouppings as they are not related to its functionality...

I'd say they are related to good code design.

Please notice, that you'd have to first redesign QObject - without it Designer wouldn't be able to do anything. So I think the issue is not in Designer itself here anyway.

I don't think so. I think it could roughly work like this:

When you call my getDesignerObject method with the parameter "group_1", it creates a container object, for the sake of the example, suppose it is a simple QList<QObject *>. Then it traverses the above mentioned QDesignerObject tree, which is an XML structure, and adds all object pointers, which belong to the "group_1" branch to the list.
Finally it returns a pointer to this list.

I reality it would not be a simple QList<Object *> since it should also carry the QDesignerMetaObjects and retain the hierarchy informations, but it still would be some sort of container.

This is just an example, that this could be added without changing QObject. The QDesignerObject would also be only a temporary transfer object to pass their content around.

Even the QDesignerObject resource tree could be deleted once the gui is built.

It might cost a little bit more time and resources to build and initialise the gui, but I don't think this would be too costly.