QT Designer? Coding by hand?

[lewis]

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


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

[lewis]

Do you use QT Designer?
Or do you prefer good old coding?

[fullmetalcoder]

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 interface

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

well, I suppose its stupid to only allow 2mins to create a poll... What if you really have to go to the bathroom!?

[lewis]

thx for removing the other thread...

[wysota]

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!?

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

#include <QWidget>
#include <QApplication>

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

To copy to clipboard, switch view to plain text mode 

It'd be better to write for example:

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

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

To copy to clipboard, switch view to plain text mode 

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... because using COTS solutions is lame ).

[Brandybuck]

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]

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]

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.

[aMan]

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

[lauranger]

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]

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/t...entry&id=87181

[smacchia]

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]

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?


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

[Chicken Blood Machine]

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]

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?

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]

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

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

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]

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]

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.