Differences

This shows you the differences between two versions of the page.

--- qt:qt_ide_options [2011/04/07 19:42] – created mithat
+++ qt:qt_ide_options [2011/12/03 18:36] (current) – mithat
@@ Line 1: / Line 1: @@
 ====== Qt IDE options ======
-  * [[Qt Creator]]
+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.
-  * [[Netbeans + C/C++/Fortran]]
-  * [[Monkey Studio]]
+===== Executive summary =====
-  * [[Eclipse + Qt Integration for C++]]
+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).
-  * [[Qt Designer + other tools]]
-  * [[QDevelop]]
-  * [[HaiQ]]
-Note: I'm not considering KDE-based and Windows-only solutions. I may not consider GTK-only solutions as well. The focus below is on C++ development because it is Qt's native binding. Some Python thoughts are sprinkled in as well though.
-Executive summary as of the moment: Despite its UI quirks and C++ only support, Qt Creator is the way to go for C++ development. Netbeans + C/C++/Fortran isn't bad, but the odd project structure is off-putting. Monkey Studio with template additions would/will be a credible alternative if debugging support improves.
 ===== Qt Creator =====
-Since this 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.
+Since the [[http://qt.nokia.com/products/developer-tools/|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 enormously confusing--even after you've been using it a while. Changing the background color helps the usability a bit (i'm currently using an olive green), 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.)
+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.
@@ Line 31: / Line 23: @@
 ==== Cons ====
   * Quirky UI
-  * At the moment, no support for PyQt/PySide. If support for Python is added, yes, yes, yes.
+  * At the moment, no support for PyQt/PySide. If support for Python is added, then by all means yes, yes, yes!
+===== Eclipse + Qt Integration for C++ =====
+The much loved/maligned Java-based IDE, [[http://www.eclipse.org/|Eclipse]], has an option for Qt support, with the support coming from no less than [[http://qt.nokia.com/developer/eclipse-integration/|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 [[http://www.eclipse.org/downloads/|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 [[http://www.eclipse.org/cdt/downloads.php|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.
+==== Pros ====
+  * "Powerful"
+  * Qt support is (semi)official
+  * The Qt templates are good
+  * Support for PyQt through PyDev as well
+==== Cons ====
+  * Quirky, often frustrating UI
+    * Closing a project leaves it visible in the workspace.
+    * Opening a new workspace resets everything
+    * Changes in "perspective" can be bewildering.
+      * There's way too much going on in a perspective
+      * It's easy to change/break a perspective
+  * The integrated Qt Designer has usability issues. You can set the IDE to use the "System editor" for a file, but Eclipse won't automatically detect changes. Re-running Qmake (or possibly some other build-oriented directive) gets the changes.
+  * The debugger stops at at ''QApplication a(argc, argv);'' A break on new thread issue?
+  * You need to manually switch back to your editing perspective after debugging.
+==== Thoughts ====
+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 + C/C++/Fortran =====
-Apparently, the classic Java IDE [[http://netbeans.org|Netbeans]] has [[http://netbeans.org/community/releases/69/cpp-setup-instructions.html|C/C++ and Fortran]] support. And even more interesting, said C/C++/Fortran package also has [[http://netbeans.org/kb/docs/cnd/qt-applications.htm|Qt support]].
+Apparently, the other classic Java IDE [[http://netbeans.org|Netbeans]] has [[http://netbeans.org/community/releases/69/cpp-setup-instructions.html|C/C++ and Fortran]] support too. And even more interesting, said C/C++/Fortran package also has [[http://netbeans.org/kb/docs/cnd/qt-applications.htm|Qt support]].
-Netbeans itself is Java/Swing based, so that means the IDE UI will look a bit goofy, but I personally <del>don't mind</del> 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.
+Netbeans itself is Java/Swing based, so that means the IDE UI will look a bit goofy, but I personally <del>don't mind</del> 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.
@@ Line 46: / Line 68: @@
   * Support for Python development is allegedly available, but development may be stalled.
   * //Automated package building in tar, deb, etc. formats(!)//
-  * Pretty [[http://netbeans.org/kb/docs/cnd/profiling-tools.html|profiling]]
+  * Pretty [[http://netbeans.org/kb/docs/cnd/profiling-tools.html|profiling]] -- but I've had trouble getting it going
-    * But I've had trouble getting it going
   * It's Netbeans--it won't become abandonware.
-    * But the C/C++/Fortran support is less guaranteed.)
+    * But the C/C++/Fortran/Qt support is far less guaranteed.
 ==== The cons ====
   *  The project structure seems to be a bit goofy. Rather than having a ''*.pro'' file at the top level, it creates different ''*.pro'' files for debug and release (along with a heap of other files) in the ''nbproject'' subdirectory. 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 ''*.pro'' file 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 [[http://forums.netbeans.org/topic24062.html|this]] for more info on importing projects.
-  * Less-than-optimal Swing font rendering (come on Oracle!)
+  * Swing's font rendering is less-than-optimal
   * You need to manually add code to the project that a more highly integrated setup (e.g., Qt Creator) would normally do for you, such as:
     * to the ''main.cpp'' file:<code cpp>#include <formname>.h</code>
@@ Line 89: / Line 110: @@
   * No profiling
   * Untested code completion
-==== TODO ====
-  * Add Beaver Debugger via PPA and see how well it works
 ==== Thoughts ====
 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.
-===== Eclipse + Qt Integration for C++ =====
-The "other" classic Java IDE, [[http://www.eclipse.org/|Eclipse]], also has an option for Qt support, with the support coming from no less than [[http://qt.nokia.com/developer/eclipse-integration/|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 [[http://www.eclipse.org/downloads/|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 [[http://www.eclipse.org/cdt/downloads.php|here]] to add C/C++ abilities. After that I downloaded the archive from Nokia and dropped it into the appropriate place.
-I've tried Eclipse for Java development a few times in the past, and each time I've walked away from it. It uses SWT, so it integrates look and feel wise fine into any supported platform. Mostly. However, one of the problems I had with this version of Eclipse is that one or more of it's many splendored panes seemed to disappear at will. I'm not talking about it changing "perspectives." I'm talking about panes disappearing when just clicking in another pane--without and seeming reason. Maybe there's something broken in my setup. Let's assume so and go boldly forward.
-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.
-Things aren't looking good.
-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 investigation into Eclipse as an option for Qt development.
-''<reboot>''
-I think I've been too tough on Eclipse. I just gave it another go and it seems to be behaving a little less unpredictably. I'm not nearly sold on the idea though, just that I'm not totally in a veto state over it.
-==== Pros ====
-  * "Powerful"
-  * Qt support is (semi)official
-  * The Qt templates are good
-  * Support for PyQt through PyDev as well
-==== Cons ====
-  * Quirky, often frustrating UI
-    * Closing a project leaves it visible in the workspace.
-      * Opening a new workspace resets everything
-    * Changes in "perspective" can be bewildering.
-      * There's way too much going on in a perspective
-      * It's easy to change/break a perspective
-  * The integrated Qt Designer has usability issues. You can set the IDE to use the "System editor" for a file, but then it doesn't detect changes. Re-running Qmake (or possibly some other build-oriented directive) gets the changes.
-  * The debugger stops at at ''QApplication a(argc, argv);'' A break on new thread issue?
-  * You need to manually switch back to your editing perspective after debugging.
-  * PyDev is totally WTF.
-==== Thoughts ====
-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. But given PyDev's bewilderification, probably not.
 ===== Qt Designer + other tools =====
 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. Another 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.
+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 won't 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.
+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.
+===== Code::Blocks =====
+For some reason, I didn't do any testing with [[http://www.codeblocks.org/|Code::Blocks]], which seems to have support for Qt projects.
 ===== QDevelop =====