Differences

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

--- qt:qt_ide_options [2011/12/03 18:25] – mithat
+++ qt:qt_ide_options [2011/12/03 18:36] (current) – mithat
@@ Line 1: / Line 1: @@
 ====== Qt IDE options ======
 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.
-  * [[#Qt Creator]]
-  * [[#Netbeans + C/C++/Fortran]]
-  * [[#Monkey Studio]]
-  * [[#Eclipse + Qt Integration for C++]]
-  * [[#Qt Designer + other tools]]
-  * [[#QDevelop]]
-  * [[#HaiQ]]
-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 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).
+===== Executive summary =====
+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 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 32: / 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++ =====
@@ Line 127: / Line 117: @@
 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 =====