What are the pros and cons in C++ Qt vs Eclipse RCP for cross-platform GUI development?

Question

I am going to develop a new GUI for an existing C++ application. The application works on Windows and Linux, and the communication with GUI is through client/server.

What are the pros and cons between Eclipse RCP and Qt?

Answer 1

Some pros of Qt:

• C++ stuff will generally perform better; however, this is arguable.
• Qt is the base of Meego, the mobile platform sponsored by Intel, AMD and others; however, its current momentum seems not too high to me. This means you can also create applications for various mobile and generally embedded devices
• There are a lot of Qt-based applications out there.
• It has a WYSIWYG designer.
• Good for small to large projects especially because of QtQuick, which allows the creation of small applications in no time and with almost zero knowledge about C++
• Qt has an amazing wrapper in Python called PyQt (there is also the PySide of course), which allows rapid development and slick prototyping. People often use PyQt (or PySide) for the UI-side of a Qt application because of that. You can of course combine with ease Python and Qt in the same application taking advantage of all their strengths (but also weaknesses). This allows relatively fast and smooth development cycles even for large projects

Some cons of Qt:

• The code of Qt-based applications make use of some elements that are not part of C++, which have to be converted into C++ by a special preprocessor called moc (Meta-Object Compiler) prior to the actual compilation. You and your build system have to take that into account.
• Nokia (former owner of Qt, since it acquired Trollech) has sold it to Digia. However, this does not imply their involvement in the development of the open source Qt has changed.

Some pros of Eclipse RCP:

• Eclipse RCP is far more than a graphical toolkit:

  • It sports a plugin-based architecture that can help distributing functionality among different components (plugins) and keeping control over dependencies among such components (plugins). Eclipse plugin system relies on their own implementation of the Java component system specification called OSGi.
  • It provides a mechanism to enable decoupled application extensibility called extension points.

• There are many Eclipse plugins that you can use in your application and many of them have distribution licenses that are friendly to commercial products.

• It has a WYSIWYG designer.

Some cons of Eclipse RCP:

• Eclipse uses a custom windowing toolkit called SWT; on each platform it relies on the native graphical layer. On Linux, it relies on Gtk+ (although it's also possible to use Motif), which in my experience (and other's) has performance problems, mostly with widgets that are updated at high rates. Actually many of us embed Swing elements in Eclipse RCP applications to overcome performance problems while keeping Eclipse's extensible architecture; this, however, can bring integration problems. There's a version of SWT that uses Qt as backend, but its incorporation into Eclipse's codebase seems stagnated since October 2010.

• Startup time (understood as the time elapsed since the application is launched until it shows up a window) of Eclipse RCP applications can be very long.

• If you intend to integrate C++ stuff with Java by means of JNI, be aware that some people find it difficult.

• Eclipse has lots and lots of bugs. Eclipse's bugzilla is a very useful resource for the RCP developer.

• The more you want you Eclipse RCP application's look&feel and behaviour to differ from Eclipse IDE, the more troubles you will get into.

• Eclipse RCP development has a big learning curve, in my opinion.

• Using Eclipse RCP for small projects is basically a suicide (unless you are restricting yourself to only creating a plugin or similar). It is meant for medium to large and very large projects due to the complexity of its infrastructure, resource requirements and the above mentioned steep learning curve.

• Eclipse RCP is not for mobile development because...it's RCP (Rich Client Platform). If you want to go mobile, this is not for you.

Both their distribution licenses (LGPL/GPL/commercial for Qt, EPL for Eclipse) are flexible enough for most uses, in my opinion. Nevertheless, I am not a lawyer, so I may be mistaken about that.

And of course, other factors like the experience of the developers, their technical skills, the size of the team, concrete requirements, etc, should be taken into account.

BTW, I have much experience in Eclipse RCP but only theoretical knowledge on Qt, so I may be biased/mistaken in my statements.

Answer 2

Now that Qt has an LGPL license I would choose Qt any day of the week over Eclipse RCP.

I have used both to create fairly complex applications.

Since you can use eclipse to develop c++, I am assuming that we are comparing mostly swt/jface vs Qt, and not the eclipse development environment itself.

Some things I have noticed having used both:

1) Qt has better documentation and samples

Other than some half-baked examples on the web, I could find little useful eclipse documentation.

2) Qt has a lot more 'professional' users

There are many professional companies out there using Qt as their UI framework. Given it's three platform support (Windows, Linux, Mac), it is very flexible, and has a lot of backing.

3) Qt tends to be more complete and mature -

Using Eclipse I noticed that quite often the controls, and packages that were available were only partially done, and not quite complete. They were typically developed for someone's use, and only coded as far as that. Qt's controls were almost always a complete design.

4) Styling.

Both Qt and Eclipse render using local platform libraries, so your UI will 'look' like other UIs on the platform you are running on (i.e. Linux vs Windows). However, Qt also provides fairly sophisticated styling functionality that allows you to easily alter the look of any control, and gives you much more control over the look of your application.

With the new declarative language (Qt 4.7.*) you are approaching WPF level of control which is really amazing.

5) UI Designer:

Qt has a much richer Designer that allows you to layout your form, and do basic testing without having to compile any code. The designer also gives you the capability to add interactions between the controls on your form. Ex. Click this button - disable this option

Eclipse also has a form designer, although my experience with it is limited. I did try to use it a couple of times with very limited success. Finally I coded every form by hand through code. That is painful.

6) Interfacing with existing source code

If you don't have this problem, then you are very lucky. Because Qt is c++ based it integrates seamlessly with legacy C and C++ code. Integrating Java and C is not easy.

7) Drawing Libraries

I tried coding some hand-drawn shapes using the swt libraries and was forced to bypass large parts of the swt drawing library, because of the cludge that was in there. Using Qt to do something similar was no trouble at all.

8) Tree and List Models

Eclipse does provide some nice out of the box functionality for propagated data into trees, and lists and things. It is almost as good in Qt, although a little trickier to set up.

9) Application Layout

Eclipse provides some nice functionality to manage 'view's (dock panels), and 'perspectives' (workflows) that if you decide to use them makes life nice and easy. Qt requires you to do this yourself. Qt does have dock panel functionality, but when building a rich application you have to set this up yourself.

Extra Note:

Qt has also provided some extra libraries to support things like xml, etc... So this helps bridge the gap a little between c++ and java for things like this.