In this article David Johnson will explain some key Qt concepts, create an example Qt program, and demonstrate how easy it is to program with Qt. This article is from the perspective of a FreeBSD developer, but the majority of it is suitable for those on any platform.
Programming With Qt
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I love QT. totally worth the licensing….
-Jason
gtkmm ( http://www.gtkmm.org/ ) does this better. It uses namespaces, the STL, has a typesafe signal/slot library (without using macros) and doesn’t need a special preprocessor.
Maybe, but the API of GTK+ sucks compared to QT. QT is way easier to learn and use.
I like GTK better. It has better docs and the API is cleaner. Gnome just looks good to me and in terms of usability it rocks!
I don’t understand why there is need for an extra step in the compilation.
It should be possible to create a callback-mechanism similar to the one in java.
I watched a movie from QT that tried to explain it but I don’t think there was any merits to their claim.
Please enlighten me!
Have you ever wondered about the lines starting with #
Those are not comment but direktives for the C preprocessor.
Now try to code C or C++ without preprocessor than come back and complain about moc.
Callbacks, like in Java, require the caller to know the callack interface. You do not need with signal/slots.
I think the video shows this quite nicely.
GTK+ is a developers worst nightmare – even the MFC are better.
Besides Cocoa Qt is the cleanest API i ever came across – I only hate that there is no “Open Source version” for Mac OS X as for all the Un*x OS.
> Now try to code C or C++ without preprocessor than come back > and complain about moc.
The standard preprocessor is just that – a standard.
This is no longer C++, but a slightly different language.
And you don’t need an extra preprocessor to implement slots/signals. Gtkmm show this by using libsigc++.
This is no longer C++, but a slightly different language
No, its only C++. moc generates source files.
Just like parser generators generate code to parse text.
You could write it manually if you wanted to, but like parsers, you usually leave that to a tool and concentrate on important stuff.
And you don’t need an extra preprocessor to implement slots/signals. Gtkmm show this by using libsigc++
I see. So how does the template do the runtime connect?
template sound like compile time to me.
There is a reason for this. When Qt came out many C++ compilers did not support those features you name. Actually, recently there was a thread on the Qt mailing list regarding their “old” style use of TRUE and FALSE vs true and false. Someone asked if anyone was really still building with compilers that didn’t support modern C++ features and up popped a bunch of responses from people still using compilers like Sun SC4 and HP/UX. The fact remains that people are locked into older compilers for various reasons, yet they can use all the Modern features of Qt (XML, Database, Widget Themes…). This does wonders for portability, just look at all the platforms Qt supports http://www.trolltech.com/developer/platforms/index.html.
I use Qt in a professional commercial environment. It has a number of very annoying flaws:
1) QString – Complete waste of time, like all compiler/library supplied string classes. It will return NULL instead of a pointer to a NULL byte if you call the ascii() or latin() method on an empty string, this is not acceptable. They should use C++ std::string.
2) Containers – Use C++ STL containers please. Vendor supplied containers generally suck, QT is no exception.
3) Threading/Networking libraries – I’ll never use these, I wouldn’t trust QT to get it right. Boost and ACE do for these. Would be nice if could licence a version that doesn’t include these.
4) Moc compiler – You can do signals and slots using pure C++ there is no need for a special pre-compilation stage.
5) Small user base (support) – Very little support for it available online. If you have a problem with the VCL or MFC someone somewhere (usually in a newsgroup posting) will have had the same problem and know how to fix it.
I certainly do not think it is worth the licensing cost. Kylix costs a lot less and comes with a full compiler (not a very good compiler I must admit though). We use it becuase it is the only cross platform framework that has a useable forms designer. Qt has the potential to become a very good product, but it’s not quite there yet.
> I see. So how does the template do the runtime connect?
> template sound like compile time to me.
I’m not sure what you mean, but in libsigc++, slot() takes a pointer to a function or method and returns a callable object that is stored in the signal object upon signal.connect(slot(foo))
>>> Euginia: “Maybe, but the API of GTK+ sucks compared to QT[…].”
Gtkmm is a C++ binding to GTK+ and gives you a nice C++ API. Expecially the signal slots system is far superior to Qt’s.
>>> patrick g: “GTK+ is a developers worst nightmare – even the MFC are better.”
One should better not confuse GTK+ with Gtkmm. Gtkmm is quite nice IMHO. The advantage Qt might have over Gtkmm are minimal and don’t justify the extra costs.
should show trolltech to these comments, they may learn something about what Qt’s problems are.
They should use C++ std::string.
This would restrict Qt to platforms with std::string implementations. See philci52’s posting.
Besides I heard std::string was not thread save.
And I personally like QString’s API better than std::string’s
Use C++ STL containers please
Nobody forces you to use Qt containers.
But some STL implementations still suck.
Very little support for it available online.
Well, I think you have less problems than with MFC.
And I have only seldom seen postings in newgroups, mailinglists or web forums not getting answered.
Kylix costs a lot less and comes with a full compiler. We use it becuase it is the only cross platform framework that has a useable forms designer.
Correct me if I am wrong, but to my knowledge Kylix is only available for one architecture and two platforms: Windows/x86 and Linux/x86.
Did I miss the Linux/PPC, Tru64/Alpha, Solrais/SPARC versions?
MacOSX? Embedded?
I’m not sure what you mean, but in libsigc++, slot() takes a pointer to a function or method and returns a callable object that is stored in the signal object upon signal.connect(slot(foo))
Hmm. not sure if this is the same level of flexibility but I guess it comes pretty close.
Would need to have a closer look to be sure.
Besides Cocoa Qt is the cleanest API i ever came across
Well personnally I started with Qt and really loved it. But Cocoa/OpenStep is really much better… try it.
I only hate that there is no “Open Source version” for Mac OS X as for all the Un*x OS.
Well, there is GNUstep, which is a reimplementation of the OpenStep API and which follows most of the changes of Cocoa … see http://www.gnustep.org .
Articles about GNUstep : http://www.roard.com/docs/
the qt-interest mailing list (http://lists.trolltech.com).. i’ve been using Qt commercially for a while, and I’ve NEVER had a question that they couldn’t answer. Their support is excellent, in my opinion.
I use the QTL more than the STL in Qt-only applications, but mixing the two is quite feasable in Qt 3.0 or beyond (as in, any modern version of Qt)
Moc is not annoying to work with at all. I don’t like gtkmm much.. the last time I worked with it, it actually seemed more inflexible than wrapping GTK+ with custom-made classes. This isn’t mentioning that it just seemed pretty incomplete. I have no idea if it has changed since then.
Oh yeah, boost is the best thing since sliced butter.. I end up using the classes in boost::smart_ptr in a whole lot of projects.
While I’ve not used GNUStep before, Cocoa is __extremely__ nice to work with. It just feels quite natural to use. It’s something that can be picked up by many programmers in an extremely small period of time.
So, if you are a new budding GUI programmer that hasn’t attached himself/herself to a toolkit/API yet, I recommend either Cocoa or Qt. .NET’s windows.forms isn’t a bad API either. Hopefully the win32 API will be cleaned up for the better in Longhorn. I really look forward with that.
PS: How far is GNUStep supported in Windows yet? Having something like Cocoa in Windows would be great.
gtk+ with libglade is the way programming should be – the interface is produced from a template at runtime. Qt offers this too, by the way.
Does GNUSTEP integrate well with Linux, Windows or mac OS X.By this I mean Qt integration, file dialogs (not on linux yet) and look and feel.
Why does the GTK2 API suck? I don’t want to hear about objects in C, that’s only relevant if you use C. Take the GTKmm API and Qt, and tell me why GTKmm sucks. Is it that you don’t like the packing system? You don’t like the widget size allocation algorithm? You prefer InterCaps to gtk_style? What?
@tr1m :
The Foundation part is (from what I’ve heard) quite stable on windows (there is even an installer for windows available on http://ftp.gnustep.org). The AppKit (eg the graphical part) lacks a good backend, there is one but it’s still alpha.
See http://www.roard.com/screenshots/gnustep_on_windows2.jpeg for example.
@Alex :
On Windows, GNUstep keeps its own look and feel. In the future I think there will be a theme more windowish. On MacOS X, well, it’s easier to not use GNUstep and simply use Cocoa ! in fact, it’s quite easy to have a same code base both for GNUstep and Cocoa, the differences between the two are small. You need to redo the nibs (using InterfaceBuilder on Mac and Gorm on GNUstep), or else use Renaissance, a GNUstep toolkit where you describe your UI in XML, and that is available on MacOS X too (thus you simply use the same Renaissance files on MacOS X or GNUstep).
On Linux, GNUstep is at the same level as Qt or Gtk, it has its own look and feel. So a “Qt integration” isn’t possible and doesn’t means anything. What you have is a common integration on standard things (drag’n drop, copy&paste..)
see http://www.roard.com/docs/lmf1.article for an introduction to GNUstep (others docs or infos on http://www.roard.com/docs/ or http://wiki.gnustep.org , http://www.gnustep.org , http://www.gnustep.us )
Kevin, which STL implementation sucks please? I would like to know, gimme some more info/references to this please.
I agree definitely with Gase, I’ve been coding using Qt for 3 months and he told 100% truth. Worst of all is IMHO the documentation&support, this just plain sucks.
If you ran into some problem it would take you ages(usually 3-5 days) to get it work correctly and know where the problem lies(whether it’s Qt problem or your missinterpretation of it). Compared this to marvelous msdn/library documentation(+ platform SDK) it makes me laugh loudly.
Qt is really killed by compatibility with old platforms, they should just forget about 50% of it and do Qt 4.x for most promising one(Linux/BSD).
P.S. Qt designer is 80% useless from principal reasons(what’s not there you must do manually hacking xml + there’s 50% things you need) and Signals+Slots are useless thing. Just use standard MVC paradigm and you would never need that.
Wow, another person who thinks the Qt documentation sucks. Could you elaborate? I’ve found the documentation to be excellent.No, it doesn’t come with four Petzold books on the CD, but the classes themselves are fully documented with tons of real examples. My experiences are the opposite of yours. Using MSDN is a nightmare of frustration for me. To each his own I guess.
The compatibility with old platforms is a plus. That’s it’s greatest strength. Qt was designed to be cross platform from day one. I ported one application from UNIX/X11 to Windows in half an hour, with most changes being due to compiler differences, and one being a difference in a system call. Porting it to OSX required zero changes. Try supporting Windows, OSX, Linux, BSD, Solaris, IRIX and Zauros with one MFC code base.
Qt Designer is a dialog editor, not a complete visual programming IDE, so don’t try using it as one. There are some features in it that seem as if Trolltech is trying to move it in that direction. This is a mistake. As a dialog editor it is superb. No, it doesn’t support every possible widget. But a lot of widgets have no place in dialogs to begin with (QCanvas),
But it was the comment about signals/slots that prompted me to respond. I have yet to see a more intuitive paradigm for object messaging. It’s Publish/Subscribe made flexible. You *should* use MVC for your application’s architecture, but at the same time you should realize that it’s not the end-all of GUI design. You can write 95% pure OO in C++ and you can write 95% pure MVC in Qt. If you need more purity than that, stick with Smalltalk. Qt will work nicely with your MVC architecture if you let it.