Unless otherwise noted, stuff below is based on experiments done in the late spring of 2011 on Debian and/or Ubuntu. I'm not considering KDE-based and Windows-only solutions. The focus below is on C++ development because it is Qt's native binding. Some Python thoughts are sprinkled in as well though.
For C++ development with Qt, Qt Creator is the way to go, despite its UI quirks and C++ only support. Netbeans with C/C++/Fortran isn't bad, but the odd project structure and PITA template creation is off-putting. Monkey Studio would/will be a credible alternative if/when debugging support improves (adding templates is easy).
Since the Qt Creator IDE is made by the Qt team for Qt development, you'd expect it to be well suited to the task, and it mostly is. However, I have two gripes.
First, the UI is quirky. The look and feel doesn't conform to any platform's standards, and it can be confusing–even after you've been using it a while. Changing the background color helps the usability a bit (i'm currently using a desaturated, dark blue), but I do wish they had gone with a more conventional setup. Another problem with the UI for me is the way it switches to layout mode when you select a *.ui file for editing. When doing so, ostensibly to capture as much screen real estate as possible, the file browser gets hidden. When you are done with layout stuff, getting back to editing a code file is a multi-click affair: click on the Edit option of the main navigation, then double click on the file you want to edit. In other words, it doesn't return to the file you were most recently editing. Instead it shows you the XML of the *.ui file you've just finished diddling with along with a message that says you can't edit *.ui files in text mode. If I can't edit *.ui files in text mode then please go back to whatever it was I was working on before I switched to layout editing! (If I want to look at the XML, I can always do via the context menu on the *.ui file entry.)
Second, the equivalent of Qt Designer is built in, but I still prefer Qt Designer for design work because (1) screen real estate isn't eaten up by the IDE's other bits and baubles and (2) the form modeling in Qt Designer gives you a fake title bar that makes visualizing the final form easier. You can open any *.ui file in Qt Designer from within Qt Creator via the context menu (much as you would to hand-edit or view the XML in an external editor), but it's not necessarily the easiest thing to do. It would be nice if the Qt Creator had a “open ui files in Qt Designer by default” option. In addition to giving me a choice of layout tools, such an option would solve one of the UI quirks mentioned above as well.
Code completion is pretty dang good.
One thing to note is that this is actually a powerful IDE. The designers have done a decent job of exposing the most used stuff and getting the less used stuff out of your way. I think for this reason there are people who think this is some kind of IDE-lite.
The much loved/maligned Java-based IDE, Eclipse, has an option for Qt support, with the support coming from no less than Nokia itself. Installing everything struck as a bit more painful than the other options. First you need to install Eclipse–but, oh, which version? Eclipse makes several different versions of the IDE available, and it's not at all clear what you're supposed to do if you want to use one IDE to develop Java, Qt C++, and maybe other programs.
I ended up downloading the vanilla “Eclipse for Java” package and used the “Install New Software…” dialog directions described here to add C/C++ abilities. After that I downloaded the archive from Nokia and dropped it into the appropriate place.
A problem that I've had with Eclipse in the past regards its approach to UI design. It seems to want to assert it powerfulness by showing you its mind-boggling power all the time. I have found the UI too distracting, too full of options, and just too “powerful”. I keep hoping that I will evolve to a point where I am not intimidated by such expressions of powerfulness, but I'm not there yet. The version of Eclipse that I tried here is easily as “powerful” as any of the others I've tried in the past.
Ok … let's try to put these concerns behind us and move on to the Qt integration. I set up a simple project without any signal/slot connections and tried a debug. It generated a cryptic warning and then rendered my window. Success, I think. Regarding the user experience of the Eclipse plugin, it integrates the equivalent of Qt Designer into the Eclipse UI. But while all of the features available in the standalone seem to be present in the plugin version, accessing the features isn't as convenient. For example, when you want to open signal/slot editing mode, you must do so from the menu bar because there's no toolbar. And when I tried to do this from the menu bar, Eclipse froze.
This ended my initial investigation into Eclipse as an option for Qt development. In my second investigation, things seemed to be behaving a little less unpredictably. I'm not nearly sold on the idea though, but I'm not totally in a veto state over it.
QApplication a(argc, argv);A break on new thread issue?
If one or more of the problems above is solved (e.g., getting the debugger to stop breaking unless you explicitly add breakpoints) it may be an alternative.
Netbeans itself is Java/Swing based, so that means the IDE UI will look a bit goofy, but I personally
don't mind sort of like how the Metal look-and-feel looks and feels (except for the file browser, which is a marathon race beyond fugly, and the font rendering, which after a gazillion years is still sucky … come on Oracle!). The Qt part of the package integrates with Qt Designer for layout tasks. It opens *.ui files directly into Qt Designer from the IDE.
I sorta like this setup. I can get my brain around it, it seems full-featured, and while it's not a platform standard look and feel, the way things work is fairly standard.
*.profile at the top level, it creates different
*.profiles for debug and release (along with a heap of other files) in the
nbprojectsubdirectory. This makes it hard to move the project to another IDE and/or import pre-existing projects. This is easily the most disconcerting con. With one export test case that I tried, moving the
*.profile up to the source files dir and making a few tweaks to the file let me open, build, and run the project in Qt Creator. See this for more info on importing projects.
<FormName> main_form; main_form.show();
In spite of the quirks, this seems to be a credible platform. It needs a good “Qt Application” project template. PyQt support is theoretically there but needs work, possibly consisting only of a “PyQt Application” project template and “Qt Form” and “Qt Dialog” file templates
Monkey Studio is a Qt-centric IDE and supports Qt projects in a number of languages. It seems to be well thought out with the exception of a couple things.
First, rather than using the standard GDB debugger directly, it uses Beaver Debugger–a wrapper for GDB stripped out of Qt Creator. A Beaver Debugger is available for OS X and Windows, but there is no package available for Linux, either in the Debian repos or from the authors.
Second, there is no template to make a Qt project with a form based on a *.ui-file. I'm pretty sure it's not a big deal to create such a template, but it would be nice if it existed by default. Starting with a Qt GUI project and then adding a Qt Form to it is a tedious and (at least for the one time I tried it) error-prone process. This is easily ameliorated with a new template.
The integrated Qt Designer is well done. That along with support for lots of languages (including Python) makes this an appealing option. The fact that it's C++-based means it starts up pretty quickly (an issue with the Java-based IDEs). Hoping that Beaver support improves.
*.profiles seem to be compatible with Qt Creator
Lack of debugging makes this less than appealing for serious work. Debugging is not available at all for PyQt projects–in spite of the good PyQt templates, etc. I really hope to see this IDE develop.
Before there was Qt Creator, I suspect a lot of people were using Qt Designer with other tools that are intended for general use but don't offer explicit Qt support. This remains a valid approach, but be aware of the pros and cons.
One pro is that this is the most portable approach. Don't like the editor anymore.? No probs – just switch. Another pro is that this approach will force you to learn more of the Qt infrastructure at the beginning rather than when something breaks and your annoyance level is high.
On the con side, you might not get get very complete code completion. Also, the lack of automation when adding forms, etc. means you will be doing a fair amount more manual coding. Both of these will slow you down and make you less excited about making changes.
For some reason, I didn't do any testing with Code::Blocks, which seems to have support for Qt projects.
Abondonware? Domain squatted.
Abandonware? Noting posted since 2009.