Slashdot Mirror
C++ GUI Programming with Qt 4
Ravi writes "When somebody talks about the Qt Framework, the first thing that comes to mind is KDE one of the most popular Desktops which is built using the Qt library. Qt is a C++ GUI framework created by the Norwegian firm Trolltech which can be used to build applications for a variety of OSes and platforms. The latest version of Qt (Ver 4.0) contains huge improvements over its earlier versions such as advanced modal/view functionality, easy to use template containers and better Unicode support just to name a few. I have been excited about the ease with which one can build GUI applications using Qt. Trolltech provides the library in two licences - the free licence which mandates that the applications developed be released under GPL and a commercial non-free licence which allows one to develop closed source applications using Qt." Read the rest of Ravi's review.
C++ GUI Programming with Qt 4
author
Jasmin Blanchette and Mark Summerfield
pages
540
publisher
Prentice Hall
rating
9
reviewer
Ravi
ISBN
0-13-187249-4
summary
A great book to learn the latest version of Qt (Ver 4.0) to create applications that run natively in Linux/Unix, Windows and Mac OS X
I found the latest book on Qt titled "C++ GUI Programming with Qt 4" authored by Jasmin Blanchette and Mark Summerfield and brought out by Prentice Hall to be a remarkable book in that it takes the readers through the basics of creating applications using the latest version of Qt and gradually shifts to explain the more advanced concepts of GUI programming using this C++ framework.
The book, all of 540 pages is divided into three parts - the first part containing 5 chapters dealing with Basic Qt, the second part titled Intermediate Qt which contains 11 chapters and the final part titled Advanced Qt containing an additional 5 chapters.
The major work in picking up skills in a new GUI framework revolves around getting to know all the classes and their member functions. And learning Qt is no different. In the first five chapters (Part I of the book), one gets to know the rudimentary concepts behind creating GUI applications using the Qt toolkit. And remarkably, instead of boring the readers with the different Qt classes, the authors take a hands on approach and introduce the concepts via examples.
In chapters 1 through 5, the readers are introduced to rapid dialog design using the Qt Designer, introduction to the main Qt classes such as QApplication, QObject, QWidget and its child classes as well as a good understanding of the concept of Signals and Slots which form the meat behind communication between different objects in Qt. Apart from that the 5th chapter also introduces to the reader the concept of Double buffering - one which is used popularly by the programmers in eliminating flicker in the GUI interface.
The sixth chapter titled "Layout Management" falls in the second part namely "Intermediate Qt". Here one gets to know and tryout the different layout classes that are available in Qt using which one can easily design sophisticated GUI applications. This chapter also gives the reader an introduction to Multiple Document Interface by way of an example.
Event Processing forms the basis of the seventh chapter where the authors explain how to catch events such as key presses and timers. Apart from that the authors also explain the five levels at which events can be processed and filtered in Qt.
Qt has an excellent collection of classes for creating 2D and 3D graphics. And from version 4, the classes are grouped into modules which need only be plugged in on a need to use basis. The primary class which deals with the 2D graphics engine in Qt is the QPainter class. The use of this class has been explained in detail in the eighth chapter titled "2D and 3D Graphics". Other than that, one also gets to know about the OpenGL module in Qt which makes it very easy to integrate OpenGL code into Qt applications as well as the classes which implement printing.
It is really interesting to see that the entire subject of Qt is apportioned into separate chapters with each chapter dealing with a particular topic. For example, if in the 9th chapter, the authors dwell on explaining the classes which implement drag and drop support, the succeeding chapter elaborates on the Model view controller architecture which forms the basis for most item view classes which implement tables, tree views and lists.
Another thing worth noting is that each chapter is explained with a complete stand alone example which makes it easy to try out what one has learned and also get a better idea of the concepts behind the classes that are explained. So while learning say about the container classes in Qt, the reader can actually try out an example and the code is accompanied by step-by-step explanations which makes it much more simpler to grasp the concepts.
All object oriented languages contain what are known as container classes - those which are responsible for creating sorted and unsorted data arrays, vectors and lists. And C++ has a couple of them in the Standard Template Library (STL). Qt has its own wide array of container classes which sport a number of improvements over STL in that they support implicit sharing (Copy on Write) which gives the applications a significant performance boost. In the 11th chapter titled Container Classes, the authors explain the concept of containers and the Qt classes that can be used for the same.
The next two chapters deal with writing and reading data from files as well as databases. And in each case, the concepts are explained with the aid of examples which makes the narration much more interesting to follow.
Qt has good support for Networking as well as XML which is evident from the 14th and 15th chapters which elaborate on the classes responsible for these. Even though these two short chapters do not cover all the networking or XMl concepts, I found them to impart a good idea of the use of a couple of important Qt classes related to networking and XML.
The 17th chapter titled "Internationalization" falls in the Advanced section of the book. I found this chapter to be an eye opener in that, with Qt's robust use of Unicode, it is possible to create applications which support a wide variety of non-english languages.
But one of the very important concept of multi-threading is explained in the next chapter titled what else "Multithreading" where the authors teach how to create threads easily in Qt.
If one looks at any KDE application, it will be evident how the parent application can be extended by use of plugins. A plugin is a dynamic library which implements a particular interface to provide extra functionality to the user. In the 19th chapter, one gets to know how to create dynamic libraries using Qt which can then be plugged into the parent application.
In the penultimate chapter, the authors explain all the platform specific features and tweaks such as using ActiveX in Windows and handling session management in X11. There are also four pages - which I believe to contain the shortest chapter I have ever come across and where a couple of classes which can be used in programming for embedded devices such as mobile phones are listed. By including this tiny chapter, perhaps, the authors were sending a signal to the developer community that Qt is fully ready for use in embedded development.
From start to finish, I found the book immensely enjoyable. The style of narration of the authors which interleaves the example code with the explanation is ideally suited to pick up skills in using any toolkit without getting bored, especially since the bulk of the learning involves acquiring a fine understanding of the classes the toolkit provides. As a bonus the book also provides an appendix which gives an introduction to C++ for programmers who use Java or C#.
The single CD accompanying the book contains Qt library in the source form for the Linux platform as well as for Windows and Mac platforms. I did not have any problems in compiling the source and installing the library in Linux using the instructions provided in the book. And within a little more than an hour (the time taken to compile the source code), I was able to start coding and compiling the examples given in the book. All in all, I find this book to be an invaluable guide in picking up skills in programming in the latest version of Qt (4.0).
Ravi Kumar likes to share his experiences in programming and in using Linux through his blog on Linux."
You can purchase C++ GUI Programming with Qt 4 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I found the latest book on Qt titled "C++ GUI Programming with Qt 4" authored by Jasmin Blanchette and Mark Summerfield and brought out by Prentice Hall to be a remarkable book in that it takes the readers through the basics of creating applications using the latest version of Qt and gradually shifts to explain the more advanced concepts of GUI programming using this C++ framework.
The book, all of 540 pages is divided into three parts - the first part containing 5 chapters dealing with Basic Qt, the second part titled Intermediate Qt which contains 11 chapters and the final part titled Advanced Qt containing an additional 5 chapters.
The major work in picking up skills in a new GUI framework revolves around getting to know all the classes and their member functions. And learning Qt is no different. In the first five chapters (Part I of the book), one gets to know the rudimentary concepts behind creating GUI applications using the Qt toolkit. And remarkably, instead of boring the readers with the different Qt classes, the authors take a hands on approach and introduce the concepts via examples.
In chapters 1 through 5, the readers are introduced to rapid dialog design using the Qt Designer, introduction to the main Qt classes such as QApplication, QObject, QWidget and its child classes as well as a good understanding of the concept of Signals and Slots which form the meat behind communication between different objects in Qt. Apart from that the 5th chapter also introduces to the reader the concept of Double buffering - one which is used popularly by the programmers in eliminating flicker in the GUI interface.
The sixth chapter titled "Layout Management" falls in the second part namely "Intermediate Qt". Here one gets to know and tryout the different layout classes that are available in Qt using which one can easily design sophisticated GUI applications. This chapter also gives the reader an introduction to Multiple Document Interface by way of an example.
Event Processing forms the basis of the seventh chapter where the authors explain how to catch events such as key presses and timers. Apart from that the authors also explain the five levels at which events can be processed and filtered in Qt.
Qt has an excellent collection of classes for creating 2D and 3D graphics. And from version 4, the classes are grouped into modules which need only be plugged in on a need to use basis. The primary class which deals with the 2D graphics engine in Qt is the QPainter class. The use of this class has been explained in detail in the eighth chapter titled "2D and 3D Graphics". Other than that, one also gets to know about the OpenGL module in Qt which makes it very easy to integrate OpenGL code into Qt applications as well as the classes which implement printing.
It is really interesting to see that the entire subject of Qt is apportioned into separate chapters with each chapter dealing with a particular topic. For example, if in the 9th chapter, the authors dwell on explaining the classes which implement drag and drop support, the succeeding chapter elaborates on the Model view controller architecture which forms the basis for most item view classes which implement tables, tree views and lists.
Another thing worth noting is that each chapter is explained with a complete stand alone example which makes it easy to try out what one has learned and also get a better idea of the concepts behind the classes that are explained. So while learning say about the container classes in Qt, the reader can actually try out an example and the code is accompanied by step-by-step explanations which makes it much more simpler to grasp the concepts.
All object oriented languages contain what are known as container classes - those which are responsible for creating sorted and unsorted data arrays, vectors and lists. And C++ has a couple of them in the Standard Template Library (STL). Qt has its own wide array of container classes which sport a number of improvements over STL in that they support implicit sharing (Copy on Write) which gives the applications a significant performance boost. In the 11th chapter titled Container Classes, the authors explain the concept of containers and the Qt classes that can be used for the same.
The next two chapters deal with writing and reading data from files as well as databases. And in each case, the concepts are explained with the aid of examples which makes the narration much more interesting to follow.
Qt has good support for Networking as well as XML which is evident from the 14th and 15th chapters which elaborate on the classes responsible for these. Even though these two short chapters do not cover all the networking or XMl concepts, I found them to impart a good idea of the use of a couple of important Qt classes related to networking and XML.
The 17th chapter titled "Internationalization" falls in the Advanced section of the book. I found this chapter to be an eye opener in that, with Qt's robust use of Unicode, it is possible to create applications which support a wide variety of non-english languages.
But one of the very important concept of multi-threading is explained in the next chapter titled what else "Multithreading" where the authors teach how to create threads easily in Qt.
If one looks at any KDE application, it will be evident how the parent application can be extended by use of plugins. A plugin is a dynamic library which implements a particular interface to provide extra functionality to the user. In the 19th chapter, one gets to know how to create dynamic libraries using Qt which can then be plugged into the parent application.
In the penultimate chapter, the authors explain all the platform specific features and tweaks such as using ActiveX in Windows and handling session management in X11. There are also four pages - which I believe to contain the shortest chapter I have ever come across and where a couple of classes which can be used in programming for embedded devices such as mobile phones are listed. By including this tiny chapter, perhaps, the authors were sending a signal to the developer community that Qt is fully ready for use in embedded development.
From start to finish, I found the book immensely enjoyable. The style of narration of the authors which interleaves the example code with the explanation is ideally suited to pick up skills in using any toolkit without getting bored, especially since the bulk of the learning involves acquiring a fine understanding of the classes the toolkit provides. As a bonus the book also provides an appendix which gives an introduction to C++ for programmers who use Java or C#.
The single CD accompanying the book contains Qt library in the source form for the Linux platform as well as for Windows and Mac platforms. I did not have any problems in compiling the source and installing the library in Linux using the instructions provided in the book. And within a little more than an hour (the time taken to compile the source code), I was able to start coding and compiling the examples given in the book. All in all, I find this book to be an invaluable guide in picking up skills in programming in the latest version of Qt (4.0).
Ravi Kumar likes to share his experiences in programming and in using Linux through his blog on Linux."
You can purchase C++ GUI Programming with Qt 4 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
At the bottom of the
Slashdot has linked to B & N here, but it seems that Amazon has it much cheaper.
Does the book explain any methods for dealing with interoperation with other frameworks? Gnome, perhaps?
I've always found that the most useful books are the ones that provide direction on how to get your application to work well with others...
P.S. F.P.
Not 4.0.
"Trolltech provides the library in two licences - the free licence which mandates that the applications developed be released under GPL and a commercial non-free licence which allows one to develop closed source applications using Qt.""
Does the latter apply to Windows?
It is too bad that this book couldn't have been based on version 4.2 coming out soon. There are some major new features in the upcoming release, most importantly (IMHO), QGraphicsView, the new canvas. http://doc.trolltech.com/4.2/qt4-2-intro.html
It also looks like they'll try to squeeze in some cool SVG related stuff. http://zrusin.blogspot.com/
Man, Qt simply pwns GTK
> Trolltech provides the library in two licences - the free licence which mandates that the applications developed be
> released under GPL and a commercial non-free licence which allows one to develop closed source applications using Qt.
So, I wonder if like MySQL people will always assume that it is free?
Well, when I write C++ code, I rarely use malloc().
I am very small, utmostly microscopic.
"I've coded a lot of GUI code, in everything. Pascal, C, C++, Java, Tcl/Tk, Perl/Tk, HTML, you name it."
Brainfuck?
I am writing this comment, using Qt4/KDE4 compiled natively for Windows.
With this build, you can use the KDE Desktop as the Windows Desktop.
The kconsoles have real scrollbars, history and resize.
You can't really tell that it is not Linux.
Oh wait..., I am using Linux.
Sorry. Let me reboot and see if I can run the unreleased windows build.
-ac
I know everyone has their favorites, but I'm curious that if you were given complete control over developing a basic multi-OS application (for arugments sake, something real simple with all the usual expected GUI boxes and features), what language combo would you use?
Yes, as the current King of Norway, I can confirm this.
does not require the application to be GPL, it requires it be open source (OSI), since the free edition is dually licensed GPL/QPL. The funny thing is that if Qt were QPL only, you could use almost all opensource licenses (eg. BSD) but not GPL, because the GPL require anythings you link with to be GPL compatible as well! So dual licensing is really necessary :)
Wondering why i am doing so strange posts? I am trying to get a "+5,Flamebait" or "-1,Insightful" rating.
Indeed, GUI development is one of the areas where managed environments shine. However, it IS possible to deal with this in C++. I agree that if I want to put a label in a window, I dont want to have to handle its deallocation, i.e. I want a "fire-and-forget" feature. I accomplished this in my wrapper by letting the parent deal with its children. It is a very simple concept, but works very well. I can write "new Label(mainwindow,"Here is my label",22,11);" and do not ever have to worry about a delete call or about memory leaks.
IMO the best thing is to make the GUI purely data-driven, however. Stuff the entire layout in a XML, and the application only has to connect its event handlers to the named signals (assuming a signals-based event dispatching mechanism). AFAIK libglade does it like this. The huge advantage is that redesigning the interface no longer requires code modification. Don't like the button position? Move it down, you dont even have to recompile.
This sig does not contain any SCO code.
Aside from also being a very good cross platform library, Qt is also just a very nice programming API period. If you are just writing Windows applications, Qt is a pretty good choice. I highly recommend it. In fact, you are soaking in it now!
Avoid Missing Ball for High Score
Fine teaching text, so far.
OSGGFG - Open Source Gamers Guide to Free Games
It is possible ... and not too difficult
instructions here
Besides the fact that some of the things you have cited have been heavily focused on in qt development, it remains a developers tool; a toolkit if you would. Qt is not aimed at users, just like WinForms isn't.
So, if it returns a zero, that could mean that there is a problem that your application may need to do something about or report, or the file does not exist, or the file exists but is zero bytes. How incredibly uninformative. But at least that member function documents its behavior it something bad happens. As I glanced through the other member functions, it became apparent that most of them do not bother to say what happens when the shit hits the fan. No return codes, no exceptions, no nothing.
Sadly, many of the classes in the library are like this. Sure, I could write an application using QT, but I wouldn't know how to handle failures simply because QT doesn't document the behavior in those cases. This is surprising, considering that QT is considered a quality library that is worthy of use in commercial applications. Granted, most of the time, we'll only execute the "happy path", and there will be no problems with this lack of documentation. However, we shouldn't throw caution to the wind and assume everything will be OK.
I can't help but think that this could have been avoided if QT would have embraced exceptions. Then, the API could avoid using C-like return codes and maintain its elegance but still report errors in a manner that is convenient for handling and documentation. QFileInfo::size() could be documented to throw QFileNotFoundException and QIOException, for example, making it easy for the user of the class to tell what happened. But they would have to rethink some of their code if they did this, because the naked-pointer-filled code that they have now would not be exception safe at all. I doubt that they will make the switch any time soon because everyone seems to be so happy with it the way it is today.
> This is exactly why I dropped Linux and went to OS X - the 4th major revision sports feature such as better basic-string handling (!!) and better programming APIs.What about overall user experience[?]
Qt is a toolkit, that means a tool for programmers. So it is only natural that is provides a better *programming* experience. If you want better user experience, you have to wait for an end user program. And I am sure that KDE 4 will deliver exactly that.
What I sometimes do is write the performance-critical parts of my program in a low-level language, usually C or C++, and bind it with Python, and have pyGTK or pyWidgets for the GUI. It gets messy handling two languages, but doing a GUI in a high-level language like Python hugely reduces GUI development time. It can also be a little boring, if not tedious, to mix C++ and Python too...
Have you ever developed a GUI for a Windows app in C++? They may well have just invented their own C++ standard... it's crazy. I developed GUI apps in VB before going to C++, before finally wiping Windows and using Linux, and even writing a GUI in wxWidgets is by far easier than Windows. wxWidgets can even take care of the main() entry point (or WinMain or what have you). In Windows, I think you required about 50 or so lines of code for a "hello world" (wxWindows isn't many lines less but it is much easier to read and follow). Horrible. Wouldn't touch it again with a 40-foot pole.
I haven't tried Qt primarily because Gnome's always been the default desktop on the distro I installed, but instantaneously I can conclude it's better than Win32 GUI programming.
DirectX is another issue... woah! I wouldn't go there again either. Once was too much. It's like taking the mangled C++ code you wrote for a Win32 GUI, mangling it further, making sure pointers are passed around like free pizza, and somehow have it spit out some form of 3D graphics and sound. To try and follow DirectX code was to me like being blind and walking through a maze, you'll eventually get there, but only after much, much effort. Maybe it's just me, but I cannot believe I ever wrote programs like I did and thought I was doing it "right".
Not trying to belittle Microsoft's programming standards or anything... cough..
You haven't used QT based on your comment. You don't use malloc. QStrings and QByteArray hide the inner workings of string manipulation, slots and signals make event handling trivial and the layout managers just work.
I've done alot of GUI development going back to System 7 on the Mac, OWL, MFC 1.0, MacApp, ET++, Starview..ect.
QT is by far the best C++ UI (and more) development environment for doing cross-platform development. And, it's a better ActiveX development than ATL or MFC.
M
But are there any good books for GTK and libglade or am I behind the times? Also, I am not talking about gnome. I would like to stay out of the gnome api and just use gtk to build a small interface but I have never attempted this so I was looking for some pointers...
I agree with the higher the better approach. On the other hand, a person calling malloc while coding in C++ probably doesn't know C++. Nor are C++ strings like C strings. Handler and callback routine setup is generally handled by the library you use (QT has a nice slots and sockets implementation. Boost also has a library devoted completely to that which can be dropped into other projects.) The "layout-bag-grid-column" will depend on whatever library or API you are using, not the language.
C++ is not C by any stretch of the imagination. It's a multi-paradigm langauge (that's both the best and worst thing about it). If there is a programming methodology out there, C++ probably supports it. Although it'll be nice if functional programming gets some help with C++0x -- Boost Lambda doesn't really cut it.
Trolltech provides the library in two licences - the free licence which mandates that the applications developed be released under GPL and a commercial non-free licence which allows one to develop closed source applications using Qt.
Does anybody know what the terms of the closed license actually are?
With LGPL'ed libraries (gtk, etc), I can make a program and flirt with selling it; that is, I guess, I can experiment with distributing something as shareware. With Qt, I might have to shell out something to Troll before I make the first penny, or at least I have to have a talk with them.
Wait a minute. Nevermind GTK. I don't even have to do that with Microsoft Windows libraries, either!! Also with GTK and Windows, I can go on past the shareware stage and sell the next big killer app and not pay anyone anything. (Well, MS will target me and destroy me on Windows, but I will have gotten farther without harrassment than I did with Qt.)
KLAATU, BORADA, NIh*ahem*
Not to stir anything up, but how does Qt compare to GTK? Could things like gaim or GIMP be redone in Qt (mostly gaim as I think GTK is a whole lot of the reason it takes up so much memory in Windows)? What kind of project would that be? Maybe I'll have to check it out and throw together a simple app or something.
It's important to point out that the core libraries of Qt, with the signal/slot mechanisms and base containers and classes, are now decoupled from the GUI libraries. This is now a good general purpose thread-safe programming library. It strikes me that signals and slots supply the advantages of weak binding, much like in Objective C and Smalltalk, and you almost wish the language had had libraries like this all along.
I for my part am very interested in PyQt or some other approach of wrapping Qt into Python as such. This could make for some very rapid development, with Python prototyping and scripting, not to mention the way you can have either C++ or Python objects receive Qt signals. Has anyone experimented with this approach? Any comments on the overhead and ease of use?
Hi,
Sorry for posting Anonymously, but I've always been more of a lurker.
Hopefully someone will read this, think it's worthy of discussion, and mod it up.
Anyway -
As an embedded developer, I'm stuck with the OS that my company has historically used (AMX).
We've used PEG for our UI work, thus far.
I see this: http://www.trolltech.com/products/qtopia, but it seems very Linux-specific.
I'd like to evaluate Qt for use in an embedded device, but I won't be able to run it on Linux.
Is it portable? How difficult would it be to get it running on another (non-Windows) OS?
Thanks!
You make a very good point. Most programmers do not make the effort to seperate UI elements from their callback infrastructure because they use inheritance to compose functioning widget heirarchies. So they combine program context with their UI. If you use composition you will be much better off, and it is easy. Create a "spineless" GUI mockup for your boss. The code should contain minimal dependencies beyond Qt or wxWidgets or whatever you are using. Implement your event handlers with minimal knowledge of the UI and attach them dynamically. With older toolkits in C you only have callback hooks so this is easy.
an ill wind that blows no good
The trouble with drag-and-drop UI designers is that the layout tends to break horribly when the window is resized or the font size changed. (I'm talking about VB, Delphi, and MFC here - there may be other frameworks that have found a way around this problem.) Designers who try to solve the problem by making their forms non-resizable should be taken outside and shot...
Well, that is exactly what Qt does. Every time you create a widget, you pass a pointer to its parent, and then you can forget about the widget. When the parent dies, it'll kill all of its children, and then they'll kill their children too in cascade. I do tons of Qt programming (that's what we use where I work), and memory management of Qt widgets is a breeze, every widget is hierarchically created, and I just need to kill the window when I don't need it anymore to have it kill all its widgets and sub-widgets. No need for a custom-made wrapper, it's all in there already.
After 3 days without programming, life becomes meaningless
- The Tao of Programming
It's obvious you've never used QT4.1.x/C++, or you wouldn't be mentioning malloc(), etc.
If I were to compare coding with the QT4 API to anything it would be Java on steroids. QT uses MOC, a meta-object compiler, to convert gui/api dependent coded to pure C++. Classes with the QOBJECT in it have automatic access to automatic memory management and garbage collection. Of course, if you use NEW its up to you to use DELETE before your method goes out of scope.
What is really nice is that I have written an app using Microsoft VC++ 2003/Qt on Windows against Oracle and compiled it on Linux against PostgreSQL with no code changes, using compiler defines to switch in and out the proper syntax at the appropriate places. It's an in-house app currently used in production. Saying it is lightening fast is an under statement.
Running with Linux for over 20 years!
http://www.bookpool.com/sm/0131872494"
crosss-pltfrm MFC roolz !!!
The best way to accelerate a windows server is by 9.81 m/s2
Check out PyQT.
Pirate Party UK
"If I were to compare coding with the QT4 API to anything it would be Java on steroids"
;-)
You mean, that's why they implemented so many Java-like features in version 4, so they could call it Java on steroids?
Or is it maybe because they took a look at Java and went "hey, there's a lot of cool stuff i there, we can use that as well!"
Case in point: I am at a university and we write software for research. We cannot release the source for various reasons, but we also do not sell the software and our goals are strictly academic. And I can't justify the license fee to the PI (principal investigator) given the alternatives. Heck, even Microsoft Visual Studio is substantially cheaper.
Flame away. I always get flamed for this argument.
C++ with MinGW and QT in the Eclipse IDE. Easy peasy
So where's the chapter on exception safety? No, I didn't think so.
Qt does not play nice with C++. If all I want to write is a GUI, Qt is great. If I want to write a program with a GUI and other functionality that requires other C++ libraries, I'm stuck with a huge impedance mismatch.
"C++ GUI Programming with Qt 4" is a misleading title. You can either write a C++ program, or a Qt program. Not both.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
I agree with your assertion in general that high-level languages are better for GUI development, but:
GUIs are a fluid, flexible, dynamic, change-on-the-fly, subject-to-change, feedback-driven kind of feature.
You're absolutely right, despite being a bit redundant. As someone who has used many languages myself, I can tell you that I can implement just that kind of GUI in almost language that I know. But just because you might pick Python over C++ because it's a high-level language doesn't mean that Python can magically "adapt" better to varying user input. Nor is C++ worse at being dynamic, or more concrete, simply because it compiles to native code. Programming languages are not adaptable that way, because no language is sentient. The programmer still has to tell the language what to do in each situation the program might encounter. Building a dynamic, feedback-driven GUI has less to do with what language you choose and much more to do with your programming skill.
The rest of this is just semantics:
you don't want to be saddled with a language which requires you to think about every malloc()
I definitely wouldn't want malloc anywhere in a well-constructed GUI. But I might be wrong here.
to manipulate strings of characters as bytes
So use C++'s string class. As for C, well, you get used to it. It's really not that bad, if you know what you're doing. (I'd recommend against using C for GUI work, though.)
to set up event handler callback routines
I've never seen a GUI toolkit that doesn't use event handlers (although they may exist). Qt uses them, Tk uses them, GTK uses them, Swing and Awk use them, even Javascript uses them. You can't get much higher-level than that.
to call methods on layout-bag-grid-column junk
If you take the time to understand it (it's not hard, and there's plenty of documentation), container-based layouts work beautifully. Many high-level language GUI toolkits use them. Or you could use something like WinForms. To each his own.
You want to build up that layout graphically
Huh? You mean by drawing it out first? UML? Using one of those drag-and-drop GUI generators?
name the elements appropriately
That has absolutely nothing to do with what language you use.
However, there may be some cut price licences out there for shareware or you probably can turn your software written on the GPL Qt into the commercial version if you have never released the software and you get a commercial licence. Perhaps look at their website - I've only looked at their GPL stuff.
Save yourself $10.20 by buying the book here: C++ GUI Programming with Qt 4. And if you use the "secret" A9.com discount, you can save an extra 1.57%! That's a total savings of $10.79, or 22.82%!
Thank god for a response from an actual programmer who know wtf exceptions are used for in C++. I cannot believe people are making excuses for broken functionality in a popular library. Someone points out that a class library is broken in one respect and others say, "so what, do this instead".
Qt does not play nice with C++. If all I want to write is a GUI, Qt is great. If I want to write a program with a GUI and other functionality that requires other C++ libraries, I'm stuck with a huge impedance mismatch.
Are you telling me that I can't pass values between Qt classes and those written by others? Can you give me some examples? I was thinking that Qt's double buffering and OpenGL support would be a nice way for me to put an interface onto some tomography code I'd written. The code is all straight C, and I thought wrapping it up in a class might be nice. Would it be harder for me to call my functions though a class than it would the straight C versions? How do the KDE programmers get around these issues?
Friends don't help friends install M$ junk.
There has been a _totaly_free_ crossplatform GUI API for many years that nobody seems to be talking about, WX.
Its C++, runs on Linux, Mac, Windows, PDAs and more! It has everything you need and its free for opensource and commercial use.
Learn at http://www.wxwidgets.org/ . . I used to be intrested in QT, but I realy didnt like the license I had to pay for something I can get for free from WX.
You just have us confused with Sweden.. We love our pretty blonde women over here in Norway - its just that they enjoy sex too much to have babies.
Have a nice day :-)
I have serious problems with the QT licensing model. I perfectly understand that they want to charge commercial developers for using their products. Heck, I won't even mind if they don't have a free version. But what I find absolutely intolerable are the terms of their commercial license.
The commercial license is tied to a named developer. That is, if I have a developer Dave who needs a QT license, I must buy a named license for Dave. It does not matter if I have unused licenses of QT lying around (which other developers don't need and are not even installed), I must still buy a license for Dave.
If Dave needs to go on a holiday or just dies and if I need Bill to complete the project using Dave's license, then the terms of the license prevents me from doing that. The license must be transferred over to Bill's name and this can be done only after 6 months! This is completely insane! Why would a company purchase a several-thousand-dollar license for a developer and face the prospect of having to purchase yet another license if the developer leaves the company / is unable to work on the project / is promoted to a non-coding role etc?
QT's commercial license fees are very high, and separate licenses are needed for each platform - that is, I need to buy QT license separately for Linux, Windows etc. Now, I perfectly understand that Trolltech can charge what they want as it is their product, but I do feel that they have made the product as unattractive an option as possible and this has resulted in huge losses to them. But again, that is their problem not mine.
I had the opportunity to review cross platform GUI toolkits for a huge project we were working on - the project was a very large public transportation project for Scandinavia and we needed a lot of licenses; I opted against QT (thereby denying them a huge order) because of these very unattractive terms in their licenses. I have had similar experiences with another project for a Finnish client as well. In both cases, I felt that QT was definitely the best framework for the job, but the licensing terms completely wiped out any of the technical advantages.
The primary problem with the QT commercial license is the fact that it makes it very difficult to bring in developers on a contract into a project for a short assignment. It becomes very difficult to reuse this license with yet another developer once the first developer's contract ends or if the first developer chooses to go elsewhere.
IMHO, Trolltech has an excellent product, but their legal and marketing departments needs to be overhauled.
Actually by default there is no race condition present due to calling QFileInfo::isFile() followed by QFileInfo::size(). This is because by default QFileInfo caches info about a file.
http://doc.trolltech.com/4.1/qfileinfo.html:
"To speed up performance, QFileInfo caches information about the file. Because files can be changed by other users or programs, or even by other parts of the same program, there is a function that refreshes the file information: refresh(). If you want to switch off a QFileInfo's caching and force it to access the file system every time you request information from it call setCaching(false)."
I wouldn't be surprised if on *nix based platforms a QFileInfo object simply calls fstat on construction.