LinuxJournal looks at Qt 3.0 and talks about why it’s such a strong and useful visual design environment. Only two serious choices for a GUI toolkit are left: Qt and GTK. When Qt 3.0 was released in October 2001, it was a singificant upgrade and was well received. The most important features of Qt 3.0 are the extensions of the utility libraries, the addition of a rich text edit widget, fabulous support for international fonts and a vastly improved Qt Designer.
Visual Development with Qt 3.0
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
As a fella who used to write code on BeOS, I have to say that when I eventually bailed and went over to linux (about a year and a half ago) I examined the various gui apis to see which, if any, had any of the feng shui that BeOS did. I’m not going to get into why various other toolkits suck (and we could debate until we’re blue in the face, anyhow), but the end of my story is that once I discovered QT/KDE I didn’t have to look any further.
All I have to say is that as an API it satisfies my long held beliefs as to what a good API should do. First, the naming conventions are rigidly upheld, and logical. Which is to say, if you know the naming conventions, you can avoid lots of documentation perusing just to find out what an expected function might be named. If you know what a method should do, you already know the name. Second, everything does what is says it does, with remarkably few caveats. Third, it intelligently uses OOP principals where they make sense, and avoids them where it does not. Too much high-falutin OOP can actually cause more trouble than it’s worth in places. An example, superficially, is that operator overloading is used almost everywhere (including iterators and whatnot) but there’s always a well-named method that does the same thing and can be used more clearly in certain circumstances where operator overloading would be confusing.
Well, I could rant, but all I can say, is that using the QT api I’ve spent the last year writing a sort of programmable autonomous nervous system for robots that I’m building in my free time. You’d think I’d not use a toolkit at all, but would focus on lower-level stuff, like standard libc and all but the fact is, QT provides many, *many* low level non-gui classes that work beautifully (for example, see QT’s fully C++ threading API, I actually prefer it to BeOS’s pthread-like c syntax). Without these classes I’d have spent waaaay more time writing the low level mechanisms and not on the higher level, meaningful, work.
And, yes, I used QT to write a nice GUI on top of it all, too
I agree with your Shamyl. QT is a very good C++ API. I said that in the past too, that (especially) BeOS programmers who want to move on and find and use a simple and elegant C++ API, Qt is the one! QT is available for most Unices, Windows and MacOSX, so you got no excuse not to try it.
I got into it a bit some months ago, and it was really easy to learn and write applications for. However, it is still not 100% thread safe. In fact, the book I got here about Qt 3.0, says that you better not use QT and multithreading too much, you will end up soon with some pretty weird conditions… 😮
Qt’s API is the best I’ve ever seen… it even beats BeOS in a number of areas (for example, you almost never need to worry about font size or pixel-placement issues, the built in layout managers handle everything nicely for you). Having the same code base compile and work the exact same way on all the major platforms is a huge plus as well. (All I need now is for someone to port Qt to BeOS… ;^))
I’ve tried it a little but I wouldn’t bother until they release a free Qt 3.0 for Windows.
I’m learning more and more about Win32 and friends. I don’t like it a bit (in fact when I think of it, I hate MS code) but it works very well in the end.
In my experience, the trouble with QT and threading has to do mainly with GUI issues.
For my nervous system code, I’ve got as many as 20 or 30 threads all humming away (one for each servo and each sensor in the robot, as well as garbage collection threads and IO-spooling threads), but they use a BMessage/BLooper-like api for communicating and messaging eachother which I wrote for the purpose of thread-safety.
On the other hand, the GUI itself has only one thread, but through judicious use of QTimer you can get the gui to regularly poll the state of some threaded mechanism and voila, you get live gui updates without having to worry about wether your GUI code is threadsafe (just as long as you know it’s safe for one thread , the gui, to poll your threaded backend). Also, you can have one thread post events to qApp and let your app’s main thread catch them. That works pretty well too, in my experience.
All in all, I have to say the absolute *best* thing about QT is the documentation.
> until they release a free Qt 3.0 for Windows
This will never happen. TrollTech’s employees have children too, and children need to eat.
QT is free for Unix, as long your application is open source. If it is not open source, you still will have to purchase a license for QT, even for Unix.
I think it is a very fair trade. What QT offers more than any other individual main API (including Carbon, Win32 or Motif and even GTK+) is that it is truly cross-platform. By using QT, you ensure that the application will have a native look, feel and behaviour among Unix, Windows and MacOSX, and all these versions will come mostly with a simple recompile (at least, most of the time). Even GTK+ can’t ensure this, which looks so SLOW, ALIEN and half-broken under Windows, while it needs the use of X under MacOSX. With QT, you do not have these problems. QT deserves the fee it requires for commercial apps, 100%.
Braaavvo Eugenia
I may run linux, I may love the GPL, but I will never hem and haw about Trolltech needing to open up QT for windows. They don’t *owe* it to us! It’s their product, it’s their hard work, and it’s their business to do what they will, with it.
Well, I don’t care much for the GPL, I was just being practical. As a poor student I just can’t afford to buy Qt. Hell, sometimes I don’t even have money to buy beer
Yes, the tripple Enterprise Edition of QT (which includes X11/Windows and Mac), which is the real deal, costs almost $4850 USD, for a single license that comes in a boxset. It is indeed very expensive for enthusiasts or for 1 or 2-man “companies”.
I would welcome a more affordable pricing scheme for smaller companies or developers. The Professional Edition does not cut it, it has only the very needed features, and no GL or DB or even network support etc. Check here for a comparison chart:
http://www.trolltech.com/purchase/comparison.html
No way about making it “free” of course, but a more affordable pricing scheme, I think it is becoming important…
>By using QT, you ensure that the application will have a native look, feel and behaviour among Unix, Windows and MacOSX
wxWindows isn’t too bad – it retains native look’n’feel for Linux/Unix and Windows and works on OS9 and OSX (but not truly native which is a pity). The docs aren’t as good as QT but still not bad, and it is free (zero cost) and has bindings to Python (wxPython) which make GUI programming a doddle.
I wish they would make it free for Windows at least for the open source projects. I don’t really think that would do much to take food out of their children’s mouth, and anyone wanting to pirate QT will do it regardless.
And $4850 is too much to pay for ANY software, unless it can cook me breakfast for me
I haven’t play enough with wxWindows, I only tried to make a “Hello World” window in wxWindows, some months ago. From what I gathered that evening is that is nowhere as simple as Qt is. It passes messages back and forth all the time, in fact, it reminded me of the MFCs.. I found it very confusing. 😮
*However*, wxWindows got it right on another aspect, an aspect where Qt has it wrong IMO. Qt is using GUI emulation in the OSes it suppors, and not API emulation (as Motif & MFC does) or API layering (as wxWindows does). This means that every time the Windows or MacOSX user change a color/icon/widget theme, the QT Windows/MacOSX applications *will not* inherit the new look, but they will look the same as the Windows or MacOSX default theme. By doing GUI emulation, the TrollTech guys say that they gain in speed (however, this is debatable), but they lose on the way their apps look after you upgrade your OS or change your theme! Under UNIX there are no such issues, because incosistency between GTK+/Motif/TCL-TK and QT apps are a reality on daily basis, as there is not a single standards body/organziation to enforce compliance, so X11 GUIs look like a circus from the GUI-consistency point of view…
> QT is a very good C++ API. I said that in the past too,
> that (especially) BeOS programmers who want to move on
> and find and use a simple and elegant C++ API, Qt is
> the one! QT is available for most Unices, Windows and
> MacOSX, so you got no excuse not to try it.
Yes, you do.
There’s no reason to use bloat-ware like GTK or Qt.Instead,
take a look at GNUstep (www.gnustep.org) – THAT’s what I
call elegant…
QT is far from bloatware. I agree, GTK+ is not elegant at all, but QT *is*. It seems that you either do not know C++, or you simply have never programmed in Qt. Plain and simple.
I have no opinion on GnuSTEP, I do not know Objective-C all that much, despite myself reading a few Cocoa books lately (now that I got a G4 Cube, I am planning to do some coding for it too
.
> QT is far from bloatware. I agree, GTK+ is not elegant
> at all, but QT *is*. It seems that you either do not
> know C++,
Yes I do. And it always gave me an uneasy feeling, that
something isn’t “quite right”.
> or you simply have never programmed in Qt.
Yes I did. For quite some time actually.
> Plain and simple.
Not so. Just take a closer look at the NeXT/Open/GNUStep
(or Cocoa for that matter) API and compare it to GTK or
Qt, and you’ll see what elegance really means. Same for
ObjC. Being the combination of SmallTalk and C, it is what
C++ should have been – true OOP, and not just one big mess
of afterthoughts.
> compare it to GTK or Qt, and you’ll see what elegance really means.
You assume too much. I am coming from a BeOS background, and BeOS and its API, are thought as the elegance in the “world of the APIs”. Also, by puting QT and GTK+ on the same sack, it is where your whole comment does not hold up. It is absolutely fine to not like both GTK+ and QT for different reasons, but by puting the two APIs on the *same* sack and firing at them the *same* blame, it is where your comment does not hold up.
Personally, I do like C++, therefore, QT and the BeOS API are great for use with C++.
You like Objective-C, fine, use GnuSTEP or Cocoa.
I was going to say the same thing since over the years I have played with a few of these x GUIs & spent serious $ (I don’t care to remember) on kits which have gone away (C++ Views etc). If you want it for free, then wxWindows is fine, def not glam. I ran all the 50 or so Win demo compiles & found the code is readable, far easier than MFC by a long shot. If I spent the time on it I could probably build what I want. But it would be real hard to produce attractive commercial grade GUI apps with it, but perfectly useable for in house projects that look a little “tired”.
The wx people never did get their 1st book together either so that holds back acceptance. I for one like to browse lots of books before I jump in with big dev effort. Of all the x GUI books I bought, Qt, is the only one that draws me in, perhaps because its not GNU. IIRC they usually include the free use version on CD, but a low $ Win license is still an issue.
The most practical thing to do for few $ would be to set up a Linux box or VM on Win & get the free use Qt license OR just use Java, it can be quite fast,…
There are other free kits, even GTK for Windows, these can be found on some x GUI web sites, there are atleast 50 of them around but most are fading away.
As a side note an attempted wx port to BeOS was started, & I even heard Trolltech was considering it before the change occured. I wonder how much they would want to do a port?
Seriously, if OBOS, Cosmoe, BlueOS etc are to go anywhere in getting a substantial no of new apps, they are going to need a x GUI kit since I don’t see many x BeOS developers jumping back to create apps & forgo the Windows, Mac $. Perhaps the OBOS crew could enlighten us on why developers should code for BeOS alone instead of a x API. I would perhaps suggest seeing if C#.net could be hijacked from Mono or BSD!!!
JJ
I recently got a Sharp Zaurus PDA, and one of the most useful things about it is that I can use the the Qt embedded API (Qtopia) and the Qt python bindings to *very* quickly create decent looking (not to mention highly useful) apps that run on my PDA. This is very cool.
Reasons why QT sucks:
MDI
MDI
multiple [goddamn] document interface
Aaaaaa! The Win 3.1 GUI
That feature (MDI) is optional and actualy takes quite a bit more work that a standard X interface
Well, you dont HAVE to make MDI apps if you dont want to,
its not forecd upon you and the API is not buiult around MDI..
And sometimes, MDI is really usefull.. IMHO
Ilan Volow, I also got a Zaurus. Right now I’m thrilled to have a shirt pocket device that I can use as a real, usable terminal. I can plug it into an Ethernet and SSH into headless boxes, or I can use the serial cable to access console / LOM ports. Sweet!
One of these days I’ll have to get around to writing some applets. Are there any good Python / Qt guides out there? Going that route holds a lot of promise for me. More than Jeode…