PDA

View Full Version : QT Designer? Coding by hand?



lewis
21st July 2006, 21:34
Do you people use QT Designer?
Or are you coding ur entire interface by hand?

Euh, there was supposed to be a poll here, but i got an error message:

You can only add a poll 2 mins after posting the thread...
:confused:

Check the other thread.... Ill try to type faster!

lewis
21st July 2006, 21:39
Do you use QT Designer?
Or do you prefer good old coding?

fullmetalcoder
21st July 2006, 21:43
It depends on :
the complexity of the interface
the time you give yourself to create the interface
the complexity of the program
the type of interfacePersonally I use Qt Designer only for complex dialogs and I never tried to use it for anything else because most of the time I subclass widgets to fit particular purposes. In such a case, using designer would be an overkill, unless your custom widgets is reusable which justify the creation of a designer plugin...

P.S: Double threading is a bad practice but maybe the poll-error is a decent excuse... ;)

lewis
21st July 2006, 21:44
well, I suppose its stupid to only allow 2mins to create a poll... What if you really have to go to the bathroom!?:eek:

lewis
21st July 2006, 21:52
thx for removing the other thread...

wysota
22nd July 2006, 02:32
well, I suppose its stupid to only allow 2mins to create a poll...
Usually people create polls when opening the thread and not after a meditation in a bathroom...


What if you really have to go to the bathroom!?:eek:
Do it before opening a thread with a poll...


About the issue with Designer. I think Designer is there for you to use it. It generates a very good code, you won't be able to write a better one yourself. And using it doesn't mean you don't know how to code a widget manually, but saves a lot of time.

Maybe my opinion will sound a bit too strong, but I think that lame people are not the ones using Designer (because "real programmers code everything themselves"), but the ones not using it. Otherwise we'd be all stuck with binary code, perforated cards or in the best case assembly.

To be honest I am thinking of writing a set of macros which would relieve me of writing the same standard things all the time (what a waste of time it is), like:

#include <QWidget>
#include <QApplication>

int main(int argc, char **argv){
QApplication app(argc, argv);
QWidget wgt;
wgt.show();
return app.exec();
}

It'd be better to write for example:

#include <QWidget>
Q_START
QWidget wgt;
wgt.show();
Q_END

There are many things like the one above... Qt already has some nice things like forever() or foreach() and of course Tulip (although real h4x0rs would say they always implement their own vectors or lists... :cool: because using COTS solutions is lame ).

Brandybuck
22nd July 2006, 04:07
Back in the 1.x days, I used Qt Architect. But as I got used to Qt I started doing all my layouts by hand. In 2.x I tried using Designer, but I didn't like it, and so stuck with hand coding. I improved enough in 3.x that I started using it. But I only used it to generate boilerplate code, which I would cut-n-paste into my own code.

In 4.x, however, I'm using Designer for all my layout, even my menus. I'll still hand code tiny layouts, however.

cristianbdg
22nd July 2006, 13:24
When I started with Qt, I always used Designer, because I thought coding a GUI by hand would be very difficult. The bad part was that every time I wanted to subclass a widget to add some functionality, I had to do a lot of work to make it play well with Designer. That's when I started reading the GUI code in the Qt examples and I noticed it wasn't that difficult. Also, I noticed that the GUI behaves more the way I want it when I code "by hand". With the arrival of Qt4 it has become even easier, because they simplified the layout classes.

So maybe it takes me a bit more time, but I prefer coding by hand.

elcuco
22nd July 2006, 23:00
I started very recently using the designer for main windows as well. With Qt4 and the auto connection mechanism, the code you need to write for making a usable application is much smaller. This leads to less mistakes and clearer code.

pir
25th July 2006, 10:03
Are there people that don't use it? If there are, I think they should get a hobby or something... and not spend the time sitting and code things by hand.

According to this poll 25% of the votes so far say that they don't use it. But I can't see any replies that states why. So I suppose that they're joking... I would really want to understand why they don't like Designer. I've always hated writing GUI code and it's the most important part of the program if you want the user to like you. It doesn't matter if your program is the best around if it's impossible to use. Without programs like Designer I would produce really bad programs, only because they would have a really crappy GUI.

But at the moment I use Designer to make the widgets and then inserts them by hand. But that is not because I think that it's better. It's just because I don't really know how to make a nice workflow when using a lot of custom widgets and the fact that I don't have Designer for Qt4...
So I insert a dummy widget instead of the custom widget in Designer and replaces it later by hand with my custom one. It's not optimal, but even by working this way I save a LOT of time and get far better results than doing everything by hand.
But there seems to be a lot better to use those ui files directly, makes it a lot easier to make changes later on if I've understood it correctly.

aMan
25th July 2006, 23:06
When I started with Qt, I always used Designer, because I thought coding a GUI by hand would be very difficult. The bad part was that every time I wanted to subclass a widget to add some functionality, I had to do a lot of work to make it play well with Designer. That's when I started reading the GUI code in the Qt examples and I noticed it wasn't that difficult. Also, I noticed that the GUI behaves more the way I want it when I code "by hand". With the arrival of Qt4 it has become even easier, because they simplified the layout classes.

So maybe it takes me a bit more time, but I prefer coding by hand.
so there are people don't using the designer..

i am using the designer.
first to have a concept: how will the program look like and how do you use it.. it is easier to think about the program when you see the gui. you know which elements you need etc..

second it's much easier to start coding for me.

regards..
aman..

mhoover
26th July 2006, 01:29
When I was new to Qt I got sent to a training seminar where they suggested that Qt was going away from the designer and going more towards hard-coding everything. A coworker told me the same thing. I guess that didn't happen?

A problem I have with hard-coding is that tweaking the sizeHint, min / max size stuff can be very tedious and slow-going. Designer makes it look good. Not "good-looking" like Apple computer good looking, but nice.

One of my friends only hard codes and his basic argument is that it's macho (but he uses eclipse to do Java ... hmm ...). IMHO there's nothing wrong with being macho (I prefer vi as an example), but laziness pays off now ;)

wysota
26th July 2006, 02:54
When I was new to Qt I got sent to a training seminar where they suggested that Qt was going away from the designer and going more towards hard-coding everything. A coworker told me the same thing. I guess that didn't happen?
I think they meant the change that happened between Qt3 and Qt4 -- the idea of writing code inside Designer was dropped and the tool evolved to become only a GUI layout editor which is meant to be integrated with real IDE software.


One of my friends only hard codes and his basic argument is that it's macho (but he uses eclipse to do Java ... hmm ...). IMHO there's nothing wrong with being macho (I prefer vi as an example), but laziness pays off now ;)
I prefer being 'smart' (h4x0r1sh?) over 'macho'...

lauranger
27th July 2006, 11:16
Hi



...

About the issue with Designer. I think Designer is there for you to use it. It generates a very good code, you won't be able to write a better one yourself. And using it doesn't mean you don't know how to code a widget manually, but saves a lot of time.

...


I can not second you about "no better code yourself" : there are unuseful and annoying lines especially for SizePolicy's and fonts where the default are better than explicit settings that, more often than never, are unwelcome.

I don't want to tag myself as reactionnary, so I have to say that even if you have to get used to QtDesigner before you can feel how to do what you want, it is better than many gui designer I've used so far.
Still, I am suspectful towards "clickodroms" for such things,
I prefer powerful layouts that permit "straightforward" tweaking (they achieve flexibility with as few (orthogonal) parameters as possible, for example).
But for some sub-parts specialized of a rich panel QtDesigner can be ok. But integration of parts is easier for me by hand.
By the way, the possibility to change a "common" property among a multiple selection would be convenient : selecting several widget that are not all in the same "containers" and are not all the children of the topmost widget and being able to set the font boldness at once, these kind of thing, would be very practical. To be constructive ;)
My2c.

jacek
27th July 2006, 11:23
By the way, the possibility to change a "common" property among a multiple selection would be convenient
Yes, hopefully it will work soon: http://www.trolltech.com/developer/task-tracker/index_html?method=entry&id=87181

fullmetalcoder
28th July 2006, 18:53
I think they meant the change that happened between Qt3 and Qt4 -- the idea of writing code inside Designer was dropped and the tool evolved to become only a GUI layout editor which is meant to be integrated with real IDE software.
And this is a good idea! But it would be even better i f the Trolls have given more docs about Designer integration and not restricted it to M$VC


I prefer being 'smart' (h4x0r1sh?) over 'macho'... Do you? I thought it was the last adjectives millionaires giving a tiny part of their fortunes chose to describe themselves... I wouldn't like to be a 'smart' guy! I fit better in something like 'neo-baba'... :D

jacek
28th July 2006, 19:44
I wouldn't like to be a 'smart' guy! I fit better in something like 'neo-baba'... :D
In Polish too? ;)

lewis
31st July 2006, 20:46
Coding by hand makes shorter, more straight forward, easier to understand and better code. Also, it helps understand how QT really works.

I do use QTdesigner sometimes, when I really cant visualize the final result because its a huge interface, but only to figure out how I will layout the objects.

Chicken Blood Machine
31st July 2006, 21:23
Coding by hand makes shorter, more straight forward, easier to understand and better code. Also, it helps understand how QT really works.

Not really. With the exception of iterative constructs, the generated code from UI files is about as straightforward and easy to understand as you can get.

I agree that handcoding helps you understand how to do that code, but once you understand the principles, you're just wasting you time with hand-coding where it can be better employed elsewhere. With handcoding, the design loop is code->compile->test->tweak->compile->test ... etc.
Using designer, you can tweak and test to your hearts content in a fraction of the time.

This is vital for complicated layouts and enhances productivity immensely.
nowadays, I just drop into hand-coding when I have something that Designer can't do (runtime changes to UI, layout changes, etc).

lewis
1st August 2006, 14:47
Coding by hand is about as fast for me... except when I forget many functions name and have to look them up all the time.

Chicken Blood Machine
1st August 2006, 18:36
Coding by hand is about as fast for me... except when I forget many functions name and have to look them up all the time.

You must tell me what this amazing compiler that you are using is then. Apparently it compiles in zero time :-)

Either that or you always code your GUIs exactly right first time :-) :-)

Brandybuck
1st August 2006, 22:52
Coding by hand is about as fast for me...
I propose a race. I create a screenshot of a simple dialog. When I say go, Chicken Blood Machine uses Designer to create the dialog, while Lewis hand codes the dialog. The winner gets all bragging rights.

Chicken Blood Machine
1st August 2006, 23:44
I propose a race. I create a screenshot of a simple dialog. When I say go, Chicken Blood Machine uses Designer to create the dialog, while Lewis hand codes the dialog. The winner gets all bragging rights.

He he! I'm game!

smacchia
6th March 2007, 13:56
There are a couple of reasons I hand code instead of designer:
1) in Qt 4.x, the designer crashed on me with complex, multi page dialogs. I reported the bug and it is reportedly fixed in 4.x, but I am leery of relying on a tool that is potentially unstable.
2) IMHO, the code generated is rather ugly
3) I like to build on re-usable tools that make hand coding easier and faster
4) My app requires highly customized colors for everything and it is easier and better to build re-usable components by hand.

wysota
6th March 2007, 14:07
1) in Qt 4.x, the designer crashed on me with complex, multi page dialogs. I reported the bug and it is reportedly fixed in 4.x, but I am leery of relying on a tool that is potentially unstable.
Which version? 4.2.2 is the most up to date...


2) IMHO, the code generated is rather ugly
Hmm... Why?


3) I like to build on re-usable tools that make hand coding easier and faster
Oh, I have to agree with you on that - me too. That's why I use designer to make hand coding easier and faster as I don't have to code all the widgets and layouts and their properties by hand.

4) My app requires highly customized colors for everything and it is easier and better to build re-usable components by hand.
Have you tried using stylesheets (http://doc.trolltech.com/latest/stylesheets.html)?


BTW. Lewis, Chicken Blood Machine - what about the contest? Any winners? :)

Chicken Blood Machine
6th March 2007, 18:18
2) IMHO, the code generated is rather ugly

I'm not sure I agree, but lets suppose this is true...Who cares? you shouldn't even have to look at auto-generated code (except when you're learning).


BTW. Lewis, Chicken Blood Machine - what about the contest? Any winners?

No image was posted, no contest was started. But I would be happy to take up the challenge any time.

smacchia
6th March 2007, 19:01
Regarding the designer crash:

Which version? 4.2.2 is the most up to date...
Yes, this version as well as 4.1 were the versions that crashed on my complex multitab dialog. I submitted the problem to Trolltech and was told it was fixed in 4.3. But as I said, I am leary of relying on tools that could be unstable.


2) IMHO, the code generated is rather ugly.

Hmm... Why?
Well because, for one thing, for each widget, it creates a giant class holding members for everything. And it can be difficult to decipher what is mandatory and what isn't. I just find it hard to read. But I guess if your using the designer exclusively, this doesn't matter.


3) I like to build on re-usable tools that make hand coding easier and faster

Oh, I have to agree with you on that - me too. That's why I use designer to make hand coding easier and faster as I don't have to code all the widgets and layouts and their properties by hand.
But, I found it a bit painful to create my own re-usable widgets from within the designer. Its just faster and easier for me to do it by hand.


Have you tried using stylesheets (http://doc.trolltech.com/latest/stylesheets.html)?
Yes & no. I've used a combination where it makes sense. There are so many "company" colors for various states, etc, that I have created a singleton for the different palettes and colors. This is almost as easy to change as a style sheet. Then my custom widgets derivations, for say pushbuttons, set the palette depending on the state, calling on the singleton for the specific palette. I found when using the stylesheet for pushbuttons, I lost the platform specific style. And in combo boxes, using the palette didn't colorize the menu for all L/F, so a style sheet worked well there. Hence the combinatory (is that a word?) approach.

wysota
6th March 2007, 22:53
But as I said, I am leary of relying on tools that could be unstable.

If the problem was fixed then what's so unstable with it? Applications have bugs, you know... there is nothing unusual in it. Bugs get fixed (introducing new bugs of course.... :cool: ) and stability improves.


Well because, for one thing, for each widget, it creates a giant class holding members for everything. And it can be difficult to decipher what is mandatory and what isn't.
The class is private, so what difference does it make? How do you code your hierarchy of widgets? In a hierarchy of classes? How would you code a QWidget having a QGroupBox with three checkboxes and a push button (sibling to QGroupBox)?


I just find it hard to read. But I guess if your using the designer exclusively, this doesn't matter.
Why read it? You can incorporate every change you may require in the implementation class (derived from QWidget or one of its descendants) not even touching the ui class.


But, I found it a bit painful to create my own re-usable widgets from within the designer. Its just faster and easier for me to do it by hand.
The disadvantage of such approach which you can't deny is that the UI has to be created by the programmer and not by a designer (meant as a person that sits all day and places buttons on forms) - every change to the design of the form has to be made by a programmer. This is not the case when using Designer. As long as you don't remove items which are referenced in the implementation class, the programmer doesn't have to do anything to have a working application.



Yes & no. I've used a combination where it makes sense. There are so many "company" colors for various states, etc, that I have created a singleton for the different palettes and colors.
It's like setting a stylesheet for the QApplication object.

This is almost as easy to change as a style sheet.
Yeah, almost :) Ever tried to get a coloured pushbutton on both WindowsXP style and Plastique with the use of palette? The same goes with many other widgets, like comboboxes - different styles use different palette roles to render the same parts of widgets.


Then my custom widgets derivations, for say pushbuttons, set the palette depending on the state, calling on the singleton for the specific palette. I found when using the stylesheet for pushbuttons, I lost the platform specific style.
Hmm... maybe you didn't use the sheet correctly? If you want a coloured pushbutton on WindowsXP or MacOS, you can't rely on the platform specific style and Qt handles that situation by itself. If you don't want the button to be coloured, the platform specific style should be maintained.

smacchia
7th March 2007, 14:14
If the problem was fixed then what's so unstable with it? Applications have bugs, you know... there is nothing unusual in it. Bugs get fixed (introducing new bugs of course.... :cool: ) and stability improves.

Perhaps, but 4.3 is also not officially out (AFAIK). And since it was broke, I had to continue development, which meant switching to hand coding. Once I switched, I decided to stay. Many of the developers here have experience with other 3rd party ui design tools and none liked the result. So even if designer is good, there is a prejudice here. I'm not saying that I wouldn't try it again for certain purposes, but I can't speak for the rest of the team here. Time will tell, we are just starting this project and I am the primary/lead on it at this point.



The class is private, so what difference does it make? How do you code your hierarchy of widgets? In a hierarchy of classes? How would you code a QWidget having a QGroupBox with three checkboxes and a push button (sibling to QGroupBox)?
It depends on how it would be used, how general purpose it is, and how long I'd have to maintain it.



Why read it? You can incorporate every change you may require in the implementation class (derived from QWidget or one of its descendants) not even touching the ui class.
True. I still prefer hand coding, what can I say?



The disadvantage of such approach which you can't deny is that the UI has to be created by the programmer and not by a designer (meant as a person that sits all day and places buttons on forms) - every change to the design of the form has to be made by a programmer. This is not the case when using Designer. As long as you don't remove items which are referenced in the implementation class, the programmer doesn't have to do anything to have a working application.
Of course, but only developers/programmers are going to muck with it anyway (at least around here). And when I used the designer, I have to say I was SO bored ;) Still, as with all tools, it can be useful and can be used when the situation fits IMHO.



There are so many "company" colors for various states, etc, that I have created a singleton for the different palettes and colors..

It's like setting a stylesheet for the QApplication object.
Not quite, but almost. This is because, there are different colors for buttons, for example, not only in and of themselves, but depending on "where" they are in the application. The QApplication pallete isn't sufficient. And it needs to be swapped depending on the context. This is true for many other controls and areas of the application. The singleton contains all the palletes for all the contexts.


This is almost as easy to change as a style sheet.

Ever tried to get a coloured pushbutton on both WindowsXP style and Plastique with the use of palette? The same goes with many other widgets, like comboboxes - different styles use different palette roles to render the same parts of widgets.
No, I don't have access to WinXP style, but I did successfully get the same color in all the styles available on Linux. It was pretty easy. We're not porting to Windows anyway. :D


Hmm... maybe you didn't use the sheet correctly? If you want a coloured pushbutton on WindowsXP or MacOS, you can't rely on the platform specific style and Qt handles that situation by itself. If you don't want the button to be coloured, the platform specific style should be maintained.
I'm not quite sure what you mean when you say "and Qt handles that situation by itself". When I set the style for a pushbutton's background only, it was flat. I think I have to set all of the other attributes and then it isn't in the platform style, AFAIK. All I wanted was to change the color, but have it have the shape and feel of the style (be it plastique, windows, mac...). Frankly it was easier to use a palette...but you're right, perhaps my lack of experience here is showing ;)

wysota
7th March 2007, 14:48
Perhaps, but 4.3 is also not officially out (AFAIK). And since it was broke, I had to continue development, which meant switching to hand coding. Once I switched, I decided to stay.
You could always use custom widgets to "hide" part of the form that causes trouble (I understand the problem was the complexity of the design).

Of course, but only developers/programmers are going to muck with it anyway (at least around here). And when I used the designer, I have to say I was SO bored ;) Still, as with all tools, it can be useful and can be used when the situation fits IMHO.


I'm not quite sure what you mean when you say "and Qt handles that situation by itself".
AFAIK it changes the style of the button.

Kumosan
2nd April 2007, 00:51
T
3) I like to build on re-usable tools that make hand coding easier and faster

Yes. this is also the reason why I don't use the designer. Ok, at first it looks like using the designer is faster. And it probably is for the pure gui design stuff. I am used to hand code my widgets, know how to use all the layout features, but I simply cannot beat drag and drop.

However, in the long run for more than small sized projects I think hand coding is much faster. I once tried to design a larger gui with the designer. A main window with a stacked widget, several actions, a couple of pages. I got a huge .h file, which I could subclass together with QMainWindow using the multiple inheritance method, which worked great. No complaint here.

Then I started to write the code. The .cpp got larger and larger. I got a super fat main window class. Of course I split the functionality in several classes, but they all depended on the designer generated .h file, with its interface blob. The whole code where such tightly coupled that it made not much difference, whether or not I left it in one single god class.

Then I pondered what would happen, it I had to add one single QLineEdit in one of the pages in the QStackedWidget. This was the moment when I deleted the whole code and swore never to touch the designer again.

I have yet to see a complex user interface, which is made with the designer and is still robust against changes, which involve more than a slight rearrangements of parts of the old design.

Maybe it is good for small things like message boxes and not too complicated dialogs. But for such small things the advantage the designer might have, isn't that convincing in my opinion.

jacek
2nd April 2007, 01:08
A main window with a stacked widget, several actions, a couple of pages.
Then maybe you should create each page as a separate .ui file?

Kumosan
2nd April 2007, 01:35
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
2nd April 2007, 02:02
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.

Chicken Blood Machine
2nd April 2007, 04:36
Maybe it is good for small things like message boxes and not too complicated dialogs. But for such small things the advantage the designer might have, isn't that convincing in my opinion.

On the contrary. I have worked on half a dozen commercial EDA applications; each composed of hundreds of thousands of lines of code; all in Qt and all with moderately complex GUIs. About 85-90% of the interface was in .ui files. The rest was hand coding and custom widgets.

wysota
2nd April 2007, 10:57
I think the only thing to remember when using Designer with really complex forms is that you can always use a custom widget - either a "real" custom widget or a "fake" custom widget which will "delegate" part of the complexity to another class. If some functionality is self contained, it is a perfect candidate for a custom widget. If you don't need to interact with it while designing, you can use a fake custom widget in a matter of seconds. If you do need to interact with it and see how it behaves, implementing a custom widget plugin is a matter of minutes. You'll waste more time correcting a single error in a hand written code.

Kumosan
2nd April 2007, 11:16
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
2nd April 2007, 11:45
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());
}

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
2nd April 2007, 12:07
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. :p



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());
}


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
2nd April 2007, 12:35
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
2nd April 2007, 13:55
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
2nd April 2007, 14:26
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
2nd April 2007, 15:30
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
2nd April 2007, 15:54
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
2nd April 2007, 16:34
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
2nd April 2007, 16:44
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
2nd April 2007, 17:08
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. :(

Kumosan
2nd April 2007, 17:30
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.