Qt is good because...
-
Using C++ we could develop faster and more native desktop applications. Unlike Java, we can easily embed OS APIs into our apps, also C++ code is much faster than languages with VMs.
Signals and slots are pretty breautiful than other libraries. It makes loose coupling。 Many other libs do follow this mechanism, such gtk+ and boost.
Also, with Qt it is easy port your apps from desktop to embeded system, from KDE to megoo, and so on.
-
A very important point for me is that Qt makes C++ development very easy and fast, and pretty clean too, beats closest competitor Java every way I look at it.
I think efficiency deserves a major focus. C++ is orders of magnitude faster than JS, QML with C++ backend is orders of magnitude faster than HTML, and in terms of memory footprint the difference is just as dramatic. With the focus falling on mobile platforms, the efficiency of native C++ code cannot be stressed enough. For example, in computation intensive tasks, C++ is on average 10-20 TIMES faster than JS, this means you can get 10-20 times as much work in a unit of time and also 10-20 more work in a single battery charge. This is very important for enterprise as well, and just because desktop computers have the power to spare doesn't really mean we should be wasting it.
Also, I didn't see anyone mentioning the truckload of examples shipping with Qt that cover the majority of the framework.
Open source is mentioned, but open governance deserves a mention as well.
-
one more...
QtSDK probably provides the best and most feature rich simulator out there for mobile devices.
Features supported, amongst others, Contacts, Messaging, Sensors, Multi-touch and Camera.
A good simulator gives instant feedback and you don't have to deploy the app to target each time.
-
Just a small, cute point:
When starting out with Qt, I developed rather complex GUI application prototype on Windows. After two weeks of writing and twisting code, I ported to Linux. All I had to take care of was to use the correct case for filenames. Well, that's about Linux, not Qt.
Otherwise it just...worked.Then I ported to Linux Embedded. Again, it just...worked.
-
It's also good regarding the licensing issues (interesting for companies):
GPL, LGPL, commercial (e.g. we are not aloowed to use GPL/LGPL code in our projects)
A very good support for commercial customers
A very helpful and active community that tries to help all
-
Thank you for all the feedback!
I will include to http://qt-project.org/wiki/Qt-is-Good what is not already there.
Is there more to say comparing Qt directly to the very own offerings of iOS, Android and Windows Phone? Language, APIs, SDK, documentation...?
-
Sadly, Qt is not officially supported on either iOS or Android, Necessitas is still WIP and has a long way to go (what is even worse, it doesn't seem to be moving at all in the moment), the same applies to iOS even more so. I personally would be happy if Qt support officially extends to those platforms, but for the time being they are more of experimental and I personally wouldn't rush ahead to market them as benefits of Qt.
That being said, as a C++ programmer I am definitely willing to give Qt the edge over the Android SDK/NDK combo. IMO Google did a very bad job with the SDK, combined with bad platform decisions for Android, for toy apps it suffices, but for serious applications with native code, the SDK/NDK combo offers a very tedious development experience, and without the NDK, performance and efficiency are awful. I compare the painting application I develop with numerous similar apps for android, both free and paid, from leading developers like Adobe and Autodesk and Qt offers better performance and more efficient resource usage.
-
Point taken - will find the words. This aims to be not only a picture but also a (not so distant) future scenario. When a developer approaches a new framework s/he also has to think not only in today but also strategically in the future.
otoh: help summarizing the best aspects of Qt Creator compared to the competition is welcome.
-
Well, for one - for plain C++, Creator's "intellisence" or auto completion is better than VS2010, which is a sad story without third party addons like Visual Assist X. Also the ability to add definitions from declarations, sync them upon changes, auto indenting, the move up/down like with indent awareness, cloning lines, refactoring and those little things that make a programmer's life easier. I haven't used other IDEs apart from Creator and VS, so those are the only ones I can compare between, but Creator is way better than VS without VAX, plus it is FREE unlike all the VS versions that support the Qt addon or VAX / other productivity boosting addons for that matter.
-
I am working for a system integration company in the machine vision sector where non-GUI parts of the software we develop is much more important than the GUI. We use both .Net and Qt.
I prefer Qt over .Net because:
- Event loop per thread makes it possible to encapsulate an object within a thread. We can talk of an object-oriented threading architecture. Other frameworks (and C++11) are task-oriented which is at odds with OOD. With thread-safe signal/slots comes thread synchronization for free.
- Several connection types for signal-slot connection empower developers with very flexible design possibilities without hitting the cross-thread exception wall and struggling with thread synchronization primitives.
- Implicit-sharing is a very powerful technology that leads to lighter classes, alleviates the need for heap-based allocation in many cases and the need for custom copy-constructor/assignment operator implementations, hence leads to cleaner, simpler code, IMHO, even cleaner than C#.
- As a C++ framework which comes prebuilt with native compilers of the supported platforms, Qt makes it possible to easily integrate 3rd party libraries into an application. When Qt is missing a functionality the platform provides, it is always possible to use the platform APIs directly, so no way of getting stuck into impossibilities. Such flexibility and independence is very very important for ISVs.
- When one gets accustomed to qmake and pro/prf/pri trio, developing and reusing an in-house library is very easy.
C/C++ is the de facto programming language in automation and machine vision industry where performance is very important and Qt is in a unique position as a C++ framework with an elegant API and advanced technologies I mentioned above.
-
Prior to Qt, I was developping desktop application with VS2005 and MFC. With MFC I spent a lot of time searching about tricks to go around the limitations of the framework. Our architect was considered a "guru" because he knew all those tricks... What a waste of time...
My first project with Qt (in 2008) was a revelation!
- Clean and logical API (pretty everything make sense)
- World class documentation (with MFC, I had to go to CodeProject or the ProgrammerExchange(!) in search for answers about undocumented "features")
- I like Qt Containers and foreach (reminds me of Ruby elegance and cleaness)
- Cross platform development is simple and effortless (just recompile)
- Qt Framework is complete and minimize the use of 3rd parties packages (and the porting efforts too)
- Qt makes coding in C++ fun and more simple
- Qt metaprogramming gives C++ some of the power of dynamic langages such as Ruby and Python
- Many wrappers exist for other langages (I've used Python's and Ruby's in the past)
- Simple and straight forward C++ testing framework comes built-in (great for TDD)
Now for QtCreator in comparison of other IDE (I've used Visual Studio and Eclipse CDT to develop Qt applications in the past) :
- Fast, lean and clean interface
- Built-in support for Qt and QMake
- Just install and you're ready to go
- Auto-completion is fast (not like in Eclipse or VS)
- Built-in support for the most popular SCM (as opposite to VS and Eclipse for which you need a plug-in / add-on for Mercurial)
- Multi-platform (you don't have to learn yet another IDE)
I'm advocating Qt whenever I can. I feel more productive and less distracted while coding in Qt.
-
I took the liberty of rewriting the paragraph about the Qt API directly on the wiki page...
I took out the "Qt has the best API available, not only in C++ but also compared to other languages" claim, which is
a) unsustainable, and
b) fails to define what "best" is even supposed to mean, and
c) mixes the concept of "framework API" with that of "programming language" in a weird way.My rephrased version is still somewhat boastful...err, I mean of course enthusiastic ;-), but I think that's okay.
-
One could easily come up with a somewhat objective concept of "the best" - although Qt is far from perfect, its portability/platform support/performance/development ease ratio DOES BEAT any other solution I am aware of.
There are plenty of good frameworks out there, unfortunately the fast ones are platform limited, and the portable ones are inferior in terms of efficiency and performance, so for the time being Qt is the beast, or the least worse if you will option, until someone bothers to make something better. That explains why I bother with it, if there was a better solution than Qt, I'd be using it instead.
Besides, I am surprised lab rats (basically anyone) can freely edit wiki pages, surely this cannot be right?
-
[quote author="ddriver" date="1333051261"]Besides, I am surprised lab rats (basically anyone) can freely edit wiki pages, surely this cannot be right?[/quote]
Well, it's a wiki, so unwelcome changes are easy to revert.
Note that Wikipedia even allows editing by anonymous IP addresses, and that hasn't stopped them from being successful...
-
[quote author="esavard" date="1332945425"]
- Cross platform development is simple and effortless (just recompile)[/quote]
One really cannot point out this one too much! It really is that easy. The only code I need to #ifdef are 3rdparty libs that are not part of Qt.
-
I'm not gonna repeat must of the good things already said about the Qt. Regarding other tool kit comparising, before I use Qt I coded in MS Visual C++ 6 with MFC. I dropped it for Qt in 2008, my personal experience is Qt has much better documentation, and examples, Qt is much more flexible in the widget UI, much more easy to use. With MFC, UI development would require much more work, more debuging, loosing hours of non UI development. Simple UI teaking in Qt, I really never could find how to do it in MFC. I have old programs I wrote in MFC, and ports in Qt, the diference is huge, Qt wins.
Also I like a lot the ideia of developing the same app for desktop and mobile, not only as in cross plataform manner, but also as a client mobile extension. For example a movie player for your pc, with a NFC remote control app for your phone, Qt makes this easier because your using the same toolkit, and this is just a small example I can think of.
-
" Sure, Android and iOS have the market cornered."
Not sure what this is based on - Symbian is still up there too (number one selling platform until 2011, and outsold Iphone for the duration of its lifetime until the WP7 switchover - whilst its sales will now inevitably fall, the installed userbase is still massive).
No platform has the market "cornered", and if we're counting two platforms together, one could just as well say "Android and Symbian have the market cornered". It's misleading to put iOS above Symbian, and misleading to put iOS on the same level of Android. If we're looking long term, it's likely to be Android alone that has much larger share than anything else.
I think it would be simpler just to leave the platorm-advocacy, and say that Qt lets you target "Android, Symbian, iOS, RIM and Linux devices". (Though as someone says above, it's probably fair to say that Android and iOS support are still unofficial WIP - Android Qt is quite viable in my experience, though has plenty of rough edges that are still being worked in.)
-
My experience before moving to Qt in 2001 was with MFC and occasionally WxWidgets. Both were much harder to learn and to do anything clever with. Even creating a scrollbar in MFC requires coding, where as in Qt it's automatic.
Cross platform development is indeed much simplified, although not entirely eliminated, especially if you're looking for high performance drawing with e.g. OpenGL. But I'd say that if you develop on say Windows, then 99% of your code will also run on Linux and even OS X without #ifdefs.
-
I have switched from Netbeans to QtCreator for C++ projects and oh my i haven't seen such an awesome IDE ever. Period.
I mean really it has everything under one hood and as c++ is my favorite language so it makes me even more enthusiastic to have such a powerful and excellent graphics framework for c++. Currently i think Qt creator is the most advanced and feature rich IDE out there.
Some features which i would like to see integrated in Qt creator are :
1 ) Ability to produce function call graph with function profiler. Much like the graph produced by cachegrind which can be viewed from KCacheGrind. So basically integrate KCacheGrind in Qt Creator itself. Afterall KCacheGrind is written in Qt for KDE.
2 ) View the memory usage for a running program.