QT Designer? Coding by hand?

[wysota]

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.

But it doesn't mean it can't be used this way. If you wanted to provide support for that in Designer, it would need to handle such a situation as well.

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

No. Before Qt4 Designer was a tool that was able to do many more things than just lay out widgets. But then Trolls decided to make Designer only a layout editor which can be embedded into real IDEs.

But if the compiler or some tool can help prevent bugs like that in the first place, it should be used.

I agree but I don't think Designer should be the tool.

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.

...based on the name. That's exactly what qFindChild does.

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.

Resources are compiled into the binary and occupy the memory all the time.

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.

Hmm... so how do you want to access the data from code if it is only to be available to the automated code? Or maybe I don't understand what you mean by "gui creation" - for me setupUi() does that.

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.

So it does the same qFindChildren() does, only on the separate object hierarchy, right?

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.

But then you could only use it in a class generated by Designer.

According to me the thing you want is a nice candidate for a completely separate component that can be implemented using Qt but not necessarily inside Qt.

[Kumosan]

Resources are compiled into the binary and occupy the memory all the time.

Really? I thought there is a way to unload them and free the memory. Q_CLEANUP_RESOURCE()? I never tried that.

Hmm... so how do you want to access the data from code if it is only to be available to the automated code? Or maybe I don't understand what you mean by "gui creation" - for me setupUi() does that.

Ah yes, I really don't meant gui creation, but hmm, how do I call it...interface dispatch? All in all I am trying to find a better way to give classes a better way to access the designer generated objects. The designer is a fine tool, I just think the way its code has to be connected to the main program code sucks.

So it does the same qFindChildren() does, only on the separate object hierarchy, right?

Actually yes, the returned object should be different. Else if you want to keep the method to encode hierarchy informations in the object name, you probably could even use qFindChildren the way it is now. But I don't think this 'reuse' would be good.

But then you could only use it in a class generated by Designer.

This I don't understand. Why?

According to me the thing you want is a nice candidate for a completely separate component that can be implemented using Qt but not necessarily inside Qt.

I am thinking how I could create such a component. I think I could create a wrapper around designer generated classes, which implements parts of the interface I described. But all depends on hierarchy information somewhere in the designer created objects. I might be willing to swallow the bitter pill and parse the object names, but then I had to set them manually. And this makes IMHO all the work pointless.

[wysota]

Really? I thought there is a way to unload them and free the memory. Q_CLEANUP_RESOURCE()? I never tried that.

This won't work for resources compiled into the application as they are part of application memory space. This macro only applies to plugins.

Ah yes, I really don't meant gui creation, but hmm, how do I call it...interface dispatch?

How would you define when "interface dispatch" ends? IMO there is no way to do that, especially if you allow subclassing.

This I don't understand. Why?

Because it wouldn't be supported by Qt core, only by the code Designer generates (just like you don't use "setupUi" with hand written classes).

I am thinking how I could create such a component. I think I could create a wrapper around designer generated classes, which implements parts of the interface I described. But all depends on hierarchy information somewhere in the designer created objects. I might be willing to swallow the bitter pill and parse the object names, but then I had to set them manually. And this makes IMHO all the work pointless.

IMO it should be completely separate from Designer with a separate tool (or two - "designer" and "compiler") handing it. Then you could incorporate it into QMake.

[Kumosan]

This won't work for resources compiled into the application as they are part of application memory space. This macro only applies to plugins.

Good to know.

How would you define when "interface dispatch" ends? IMO there is no way to do that, especially if you allow subclassing.

Yeah, probably only through evil hacks. But I don't like to think about code with never will be too deeply now.

Because it wouldn't be supported by Qt core, only by the code Designer generates (just like you don't use "setupUi" with hand written classes).

The QDesignerObject I meant is a simple container class, which is generated by designer generated code. All it has to do is implement a well defined interface. It could even be a subclass of QObject, though this would be overkill. But even if it is nowhere else supported in Qt, I would only need the header file of the interface. Maybe I am a bit blockheaded at the moment, but I cannot follow you here.