QT Designer? Coding by hand?

[Kumosan]

Then maybe you should create each page as a separate .ui file?

Yes, thought of that. But this diminishes the usefulness of the designer a bit, and still does not really mitigate the robustness problems.

I think the designer generated code is only usable where it is absolute sure that the requirements don't change.

Suppose I have a widget with three buttons. I can connect each button with its own slot. When I add a fourth button, I have to write a new slot with all the changes in all clients, which are interested in the new buttons signal. This is more or less the way the designer code imposes.

If I hand code my widget I can use a QButtonGroup, have one signal, which identifies its button via its index. This is a little bit more flexible. I don't know whether there are tricks, which allow something simple like that with the designer.

But even if there is a way, I can go even further. Subclass a button using a specialised interface, design my widget that a factory method can easily add such a custom button dynamically during runtime. Other clients can register to query what buttons are actually there, and connect to the desired signal. If this is done correctly, only one class, the factory method, has to be changed, to add an additional button.

Ok, this might be overkill in many cases, and I don't code always that way. But I learned the hard way that especially user interfaces are bound to change. And of all things, especially the part of a program, which is most likely to change and to be enhanced over time, is produced by a tool, which produces the most rigid code possible.

[jacek]

I think the designer generated code is only usable where it is absolute sure that the requirements don't change.

What I believe is that it's easier to reorganise the GUI or add something to it using Designer, instead of changing the hand-written code. Moreover Designer doesn't make mistakes, of course you can still make some errors when you use Designer, but certainly they aren't hard to find, because of the visual nature of Designer's interface.

If I hand code my widget I can use a QButtonGroup, have one signal, which identifies its button via its index.

You can use QButtonGroup with Designer-generated code too --- the same way as if you were using in hand-written code.

Subclass a button using a specialised interface, design my widget that a factory method can easily add such a custom button dynamically during runtime.

You can create a custom widget (something like a QDialogButtonBox) and place it on the form, but of course you can always find such a complex situation when Designer isn't enough. It's just a tool, not the Ultimate Answer to the GUI Design Problems(tm), yet you should squeeze as much as you can from it and hand-code the rest.

[Kumosan]

You can use QButtonGroup with Designer-generated code too --- the same way as if you were using in hand-written code.

Do you have a different designer? I mine I don't see 'Button Group' in the widget box. Of course, you can add all buttons manually into a QButtonGroup. But then the code has to change when you add another button. With QLineEdits it is even worse, there is no such thing like a QLineEditGroup.

But I might believe that for all my problems a workaround is possible. Only that if you constantly have think of workarounds for the shortcomings of the designer, the speed bonus is quickly gone.

But after the postings yesterday I thought a bit whether I could find a way to improve the designer. Just sent a feature wish to TT.

My idea:

A graphically designable parent/child tree like the QObject parent/child tree + some attachable meta informations. I call this designer meta objects. The designer would automatically generate a query method and a factory method. The query method gives you a list of meta objects. The factory method creates meta objects.

The meta objects contain pointers to the objects inside + the attached meta informations. Pointer to those created meta objects could be passed to clients.

So the gui 'kernel' code could be very small. It inherits only the designer generated classes. Multiple inheritance of QMainWidget, or QDialog or whatever would not be necessary anymore.

The kernel only contains mainly two methods: contains and a creator.
A client could ask the gui kernel if it contains a meta object for the third page in a QStackedWidget. If yes, it asks the kernel to create such an object and give it a pointer to it.

If this is done right, you could start your designer, add a couple of widgets like buttons or lineedits, and it would still work without a single line of code changed in your program.


Creating such a parent/child relationship would be as easy a putting objects on a layout tree.

[wysota]

Do you have a different designer? I mine I don't see 'Button Group' in the widget box.

QButtonGroup is not a widget.

Of course, you can add all buttons manually into a QButtonGroup. But then the code has to change when you add another button. With QLineEdits it is even worse, there is no such thing like a QLineEditGroup.

When you don't use Designer you have to add these buttons to the buttongroup yourself anyway, so I don't see where the "hand code only" way is superior...

But I might believe that for all my problems a workaround is possible. Only that if you constantly have think of workarounds for the shortcomings of the designer, the speed bonus is quickly gone.

I think you're the one making workarounds... Query? Register? Factory? Aren't these workarounds?

A graphically designable parent/child tree like the QObject parent/child tree + some attachable meta informations. I call this designer meta objects. The designer would automatically generate a query method and a factory method. The query method gives you a list of meta objects. The factory method creates meta objects.

Could you suggest any other use than yours for such a feature? How is this related to a layout editor?

If this is done right, you could start your designer, add a couple of widgets like buttons or lineedits, and it would still work without a single line of code changed in your program.

I don't see a problem with doing it without any changes to designer. Just like you have automatic signal-slot connections, you can make automatic "button group additions", for example based on object names, try this:

QList<QPushButton*> candidates = findChildren<QPushButton*>(QRegExp("bgbutton_[0-9]+"));
foreach(QPushButton *candidate, candidates){
  QRegExp rx("bgbutton_([0-9]+)");
  rx.exactMatch(candidate->objectName());
  buttongroup->addButton(candidate, rx.cap(1).toInt());
}

QList<QPushButton*> candidates = findChildren<QPushButton*>(QRegExp("bgbutton_[0-9]+"));
foreach(QPushButton *candidate, candidates){
  QRegExp rx("bgbutton_([0-9]+)");
  rx.exactMatch(candidate->objectName());
  buttongroup->addButton(candidate, rx.cap(1).toInt());
}

To copy to clipboard, switch view to plain text mode 

No need to change a single line of code outside Designer... You can do the same thing with other widgets as well... even making automatic connections for line edits or whatever you want.

Creating such a parent/child relationship would be as easy a putting objects on a layout tree.

What layout tree?

[Kumosan]

QButtonGroup is not a widget.

Correct, but irrelevant. There is no way to create buttons in a QButtonGroup within the designer. At least none I know.

When you don't use Designer you have to add these buttons to the buttongroup yourself anyway, so I don't see where the "hand code only" way is superior...

It is easier to do it by hand. With the designer you first have to think about the layout and then how to conveniently access all the stuff in the generated code. But this might be a matter of personal taste.

I think you're the one making workarounds... Query? Register? Factory? Aren't these workarounds?

No. A workaround is something you need when you want to do things, which the designer cannot do naturally. Should my ideas be implemented, they would not be workarounds.

Could you suggest any other use than yours for such a feature? How is this related to a layout editor?

What other use? It is an additional abstraction of the designer created interface. There would be thousand uses. It would be an enhancement of the layout editor. You would not only layout the geometrical arrangements of the single widgets, but give them a logical structure.

I don't see a problem with doing it without any changes to designer. Just like you have automatic signal-slot connections, you can make automatic "button group additions", for example based on object names, try this:

QList<QPushButton*> candidates = findChildren<QPushButton*>(QRegExp("bgbutton_[0-9]+"));
foreach(QPushButton *candidate, candidates){
  QRegExp rx("bgbutton_([0-9]+)");
  rx.exactMatch(candidate->objectName());
  buttongroup->addButton(candidate, rx.cap(1).toInt());
}

QList<QPushButton*> candidates = findChildren<QPushButton*>(QRegExp("bgbutton_[0-9]+"));
foreach(QPushButton *candidate, candidates){
  QRegExp rx("bgbutton_([0-9]+)");
  rx.exactMatch(candidate->objectName());
  buttongroup->addButton(candidate, rx.cap(1).toInt());
}

To copy to clipboard, switch view to plain text mode 

Yes, and this is what I call a workaround.

What layout tree?

You know how to put layouts inside layouts? This is a layout tree. You position object geometrically in it. The same way you could group
meta information of the objects in your designer generated code.

[wysota]

What other use? It is an additional abstraction of the designer created interface. There would be thousand uses. It would be an enhancement of the layout editor. You would not only layout the geometrical arrangements of the single widgets, but give them a logical structure.

Name one.

Yes, and this is what I call a workaround.

No, this is not a workaround - this is a general way of doing things based on object names. Using it to put buttons into a button group is just one of the use cases. You might use the same approach to... I don't know... for example apply event filters, modify properties on multiple objects or do anything else you like if you don't have pointers to objects but know their name pattern. Remember that a button group doesn't have anything to do with the layout of objects, so you can't put a QButtonGroup object on a form and assign buttons as children to it.

You know how to put layouts inside layouts? This is a layout tree. You position object geometrically in it. The same way you could group
meta information of the objects in your designer generated code.

But what is the point of "grouping meta information of objects"? Would you like to use them in Designer or in the hand coded class making use of an ui file? I can imagine having a separate mode for Designer for such things but I don't see any benefit for a larger group of people (which is the only thing capable of making Trolls implement this).

[Kumosan]

No, this is not a workaround - this is a general way of doing things based on object names.

And I think this is a terrible hack like way. I some sense you do hand coding within the designer. You have to think of a naming scheme. You have to use regexp to use it. Your naming scheme can easily break, when you layout changes too much.

Remember that a button group doesn't have anything to do with the layout of objects, so you can't put a QButtonGroup object on a form and assign buttons as children to it.

Please don't take me literally. And please be a bit more observant when I use examples, e.g. when I try to explain a possible feature in terms of already exiting ones.

And I can very well put a QButtonGroup on a form. At least in theory, it is just not implemented. It could be implemented as dropping a rectangle on the form, giving it a name, dropping buttons in it. Later on the uic compiler creates a QButtonGroup which is populated with the buttons I dropped in. There is no universal law that the designer can handle only layouts.


Btw. my idea of a designer meta object consists of several parts. The first part is not that different from that what you are doing. It could even be implemented using the object name (though I would not do so). You create an meta object tree just like you create a layout tree (Attention Example, it is not a layout. It is just used the same way by dropping boxes in boxes.). You drop your widgets in those meta object boxes, name those boxes, and this way your object names are created automatically in a well defined naming schema.
This would be cramming all meta information in this single string. Ugly, but possible.

But what is the point of "grouping meta information of objects"? Would you like to use them in Designer or in the hand coded class making use of an ui file? I can imagine having a separate mode for Designer for such things but I don't see any benefit for a larger group of people (which is the only thing capable of making Trolls implement this).

This would be the second part of my idea. I would use them outside the designer. You create a naming schema manually and parse them in the subclassed object, e.g. you create a QButtonGroup, search all children of the ui class for a certain name to add it to the button group. Finally you then can pass a pointer of the button group to the object, which actually handles the buttons. Next you search for other parts in the ui class, dispatch gui parts to the correct handler, etc.

As I said, this is ugly, you have to remember your naming schema and if it changes, your regexps might have to change, too. Furthermore you enter your object names manually, which is error prone. One typo and the debugging starts.

With my idea you generate your object names (or other meta info) graphically. Effectively grouping your objects, e.g. you create a meta box and give it the name 'page_1' in this box you drop a second meta box and give it the name 'group_1'. Now you drop a button in the second box and it is automatically named page_1.group_1.button_1. No, this has nothing to do with layout. I just uses the same user interface to create a tree.

This is something you could do manually. The way you do it, you now would create some loops, some regexps, which parse the object names.

I'd like to have an auto generated query method where I can ask 'contains("page_1"). If the answer is true, I'd like to have a method

"QDesignerObject *getDesignerObect("page_1")",

This returned QDesignerObject should contain references to group_1 + all children + meta information. Now I can pass this object, which encapsulates a small logical part of the whole gui to a client class, which handles the stuff inside this object, e.g. group_1 and its buttons.

[wysota]

And I can very well put a QButtonGroup on a form. At least in theory, it is just not implemented. It could be implemented as dropping a rectangle on the form, giving it a name, dropping buttons in it. Later on the uic compiler creates a QButtonGroup which is populated with the buttons I dropped in.

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. I can imagine the thing you want to be implemented as a separate working mode for Designer where you could somehow "associate" buttons into groups. But, let's face it, it would be really rarely used.

There is no universal law that the designer can handle only layouts.

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

Btw. my idea of a designer meta object consists of several parts. The first part is not that different from that what you are doing. It could even be implemented using the object name (though I would not do so). You create an meta object tree just like you create a layout tree (Attention Example, it is not a layout. It is just used the same way by dropping boxes in boxes.). You drop your widgets in those meta object boxes, name those boxes, and this way your object names are created automatically in a well defined naming schema.

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...

you have to remember your naming schema and if it changes, your regexps might have to change, too.

Actually, not necessarily. And even if this is the case, I don't really see a problem with it.

Furthermore you enter your object names manually, which is error prone. One typo and the debugging starts.

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'd like to have an auto generated query method where I can ask 'contains("page_1").

In what way is it different than qFindChild()? You could make the same typo with both approaches...

If the answer is true, I'd like to have a method

"QDesignerObject *getDesignerObect("page_1")",

Again, qFindChild() does that...

This returned QDesignerObject should contain references to group_1 + all children + meta information. Now I can pass this object, which encapsulates a small logical part of the whole gui to a client class, which handles the stuff inside this object, e.g. group_1 and its buttons.

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. But I don't see why Designer should handle such grouppings as they are not related to its functionality... 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.

BTW. I remember something about Designer being able to handle "user properties" since 4.3 (I'm not sure if this was exactly what I think). If that was the case, you could create a user property "in button group 1" and set it to true for all buttons you wanted in the button group and then only iterate over all buttons and check the property value, adding them to a particular group. Of course you'd still have to add buttons to the group from within code.

[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.

[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]

BTW. I remember something about Designer being able to handle "user properties" since 4.3 (I'm not sure if this was exactly what I think). If that was the case, you could create a user property "in button group 1" and set it to true for all buttons you wanted in the button group and then only iterate over all buttons and check the property value, adding them to a particular group. Of course you'd still have to add buttons to the group from within code.

After you wrote this I had to check in the Qt 4.3 designer. You are right. right clicking the property editor opens a popup, which allows you to add a 'dynamic propery'. This handles most of the parts, which I named QDesignerMetaObject.

Unfortunately I cannot use the 4.3 designer. In 4.3.0beta the preview window has no window decorations. I cannot close a preview window and have to brutally kill the program.