Qt Designer vs Handcoding

Question

Every time I start a project with some graphical toolkit, one of the first conflicts happen with the decision of how to deal with the visual design and the widget layout: A graphical tool or handcoding?

This is a quite tricky/subjective question because most people will decide based on personal preference. It also depends greatly on the quality of the graphical tool. In this case I would like to focus just on the latest version of the QT library. I do not intend to discuss which method is better. I am convinced that the best answer is: depends on the project.

What I want is a reference to a good non biased article, based on experience after several projects. The article should just describe the tradeoffs of both choices

Answer 1

I started with doing everything hand-coded, and of late have been switching to using Qt Designer for most forms. Here are some benefits for each position:

Using Qt Designer

• The biggest time saver for me is managing complex layouts; it saves a lot of tedious coding. Simply (very roughly) arrange your widgets, select them, right-click, and put them in the correct type of layout. Especially as layouts become nested, this is so much easier.
• It tends to keep your implementation files cleaner instead of filling them with all the boilerplate layout code. I'm type-A, so I like that.
• If you are translating your application, it is possible to send your translators the .ui files so they can see on your GUI where the text they are translating will be. (Assuming they are using Qt Linguist.)

Hand-coding

• Control. If you have a layout where you need to instantiate / initialize the controls in a very particular order, or dynamically create the controls based on other criteria (database lookup, etc.), this is the easiest way.
• If you have custom widgets, you can kind-of-sort-of use the Designer, adding the closest built-in QWidget from which your class derived and then "upgrading" it. But you won't see a preview of your widget unless you make it a designer plugin in a separate project, which is way too much work for most use cases.
• If you have custom widgets that take parameters in their constructor beyond the optional QWidget parent, Designer can't handle it. You have no choice but to add that control manually.

Miscellaneous

• I don't use the auto-connect SLOTS and SIGNALS feature (based on naming convention such as "on_my_button_clicked".) I have found that I almost invariably have to set up this connection at a determinate time, not whenever Qt does it for me.
• For QWizard forms, I have found that I need to use a different UI file for each page. You can do it all in one, but it becomes very awkward to communicate between pages in any kind of custom way.

In summary, I start with Qt Designer and let it take me as far as it can, then hand-code it from there. That's one nice thing about what Qt Designer generates--it is just another class that becomes a member of your class, and you can access it and manipulate it as you need.

Answer 2

My answer is based on two years developing biochemistry applications using PyQt4 (Python bindings to Qt 4) and OpenGL. I have not done C++ Qt, because we only used C++ for performance-critical algorithms. That said, the PyQt4 API greatly resembles Qt4, so much here still applies.

Qt Designer

• Good
  • Exploration. Discover what widgets are available, the names for those widgets, what properties you can set for each, etc.
  • Enforces separation of UI logic from application logic.
• Bad
  • If you need to add or remove widgets at run-time, you have to have that logic in code. I think it's a bad idea to put your UI logic in two places.
  • Making changes to nested layouts. When a layout has no widgets in it, it collapses, and it can be really hard to drag and drop a widget in to the location you want.

Hand coding

• Good

  • Fast if you are very familiar with Qt.
  • Best choice if you need to add or remove widgets at run-time.
  • Easier than Qt Designer if you have your own custom widgets.
  • With discipline, you can still separate UI layout from behavior. Just put your code to create and layout widgets in one place, and your code to set signals and slots in another place.

• Bad

  • Slow if you are new to Qt.
  • Does not enforce separation of layout from behavior.

Tips

• Don't just jump into creating your windows. Start by quickly sketching several possible designs, either on paper or using a tool like Balsamiq Mockups. Though you could do this in Qt Designer, I think it is too tempting to spend a lot of time trying to get your windows to look just right before you've even decided if it is the best design.

• If you use Qt Designer for PyQt, you have the extra step of running pyuic4 to compile your *.ui files to Python source files. I found it easy to forget this step and scratch my head for a second why my changes didn't work.

• If you code your UI by hand, I suggest putting your layout code in one place and your signals and slots in another place. Doing this makes it easier to change the way your widgets are arranged on a window without affecting any of your application logic. Or you can change some behavior without having to wade through all the layout code.

Enjoy Qt! Now that I am using Java Swing for work, I miss it.

Answer 3

I tend to layout dialogs using the designer but I do all the event handling stuff in the main code. I also do all the main windows, toolbars, menus in direct code.

The designer is just frustrating - a pity since decent drag and drop sizer based designers have been around for more than a decade

Answer 4

It depends on the number of different windows/panels you need for your application. If the number is small, use a graphical tool. It is much faster to get a few windows designed perfectly. If the number is large, the graphical tool can (and should) only be used for prototypes. You need to code the layout to be able to make application-wide changes at acceptable cost.

That includes creating a model of how the UI of the application works and dynamically adding and removing widgets at runtime. For an excellent example of such a model (in a different environment), take a look at the glamour model for creating object browsers.

I object to the suggestion that it is tricky/subjective (at least more than other development choices). It is easy to come up with criteria to decide on. Personal experience and preference are important for that, as they decide when the number of different windows should be considered small. The same goes for tool quality.