Perhaps the recent KDE and Qt releases made you want to contribute to KDE or to start your own Qt/KDE application? Then you may be interested in the new "C++ GUI Programming with Qt 3" book, the first official Trolltech guide to Qt 3.2 programming. It's written by Trolltech software engineer Jasmin Blanchette and Trolltech's documentation manager Mark Summerfield, with a foreword by Matthias Ettrich, Trolltech lead developer and founder of the KDE project.

The table of contents shows that book teaches every facet of Qt 3 programming, ranging from basic user interfaces and layout managers to 2D/3D graphics, drag-and-drop, signaling, networking, XML, database integration, even internationalization and multithreading. The "Layout Management" chapter is available as sample in PDF format. The accompanying CD contains the book's code examples, the Qt 3.2 Free Editions for Unix/Linux/Mac OS X and a special Qt 3.2 Non-Commercial Windows Edition for Open Source developers together with a compiler (Borland C++ 5.5 Non-Commercial Edition).

Comments

So if I understand this correctly, I can buy the book and compile my C++ + STL + Qt apps for the people that are still using windows, without needing anything but e.g. Windows XP and the accompanying CD?

That would be great! Finally a use for the XP parition on my laptop. (although putting music on it would a good idea too)

If you make the same application for the same customers availabe at no cost perhaps. Your behavior is the exact reason why there was no current non-commercial Qt Windows edition available for such a long time.

Trolltech is stupid not to release one, if they had a GPL edition available than that would automatically popularize all their platforms bringing more life to Mac and Linux too due to the crossplatform nature of Qt and the availability of source, the best GPL applications for Windows would be availabe in Linux too.

Not to mention that they would be able to get free press from 95% of the computer using world and therefore interest many more people.

Really, I am very dissapointed in that aspect and I think the trolls are acting foolishly.

I have the QT Non-Commercial edition and its compiled so it can only be linked to dynamically, not statically, it also requires the non-commercial edition installed on the computer to run. Plus it puts [Non-Commercial] at the front of the main windows title.

It doesn't matter if your app is commercial or not. What matters is if it's proprietary. You CAN use the GPL/free Qt for commercial GPL software. You CAN'T use the GPL/free Qt for non-commercial proprietary software. There's no relationship between whether your app is commercial and whether you can use the GPL'd Qt.

If you want to develop proprietary apps (commercial or otherwise), you need the "commercial" Qt. Trolltech's choice of language really muddies this whole issue. If in doubt, just read the GPL and see what it allows you to do.

The question concerned the non-commercial Qt that comes with the book, not the GPL/QPL edition for X11 or MacOS. In reference to the book edition it actually *does* matter if the application is commercial.

"10. Distribution of the Applications are subject to the following requirements:
(i) The Application(s) must be distributed for free and/or be freely downloadable;
(ii)The Application(s) must be licensed under a license which is compliant with the Open Source Definition version 1.9 as published by the Open Source Initiative [...]"
(Qt Book Edition Non-Commercial License Agreement North and South America Agreement version 1.1)

So the application that links to the non-commercial Qt must be open source and available at no cost.

Indeed, I bought the book for this very reason, as I am in a Computer Graphics class where I must turn in my projects on Windows, but my testing/development box runs Linux. This makes my task incredibly easier (I had been using FLTK+OpenGL earlier).

Be aware, however, that the Qt Windows Non-Commercial edition is distributed as a shared library (DLL), not a static library. You can't redistribute the Qt Non-Commercial from the book, but I'm not sure if that applies to the Qt DLL itself, as it will obviously be required for the program to run.

Actually, I just checked the license:

11. Copies of Redistributables may only be distributed with
and for the sole purpose of executing Applications
permitted under this Agreement that Licensee has created
using the Licensed Software. Under no circumstances may any
copies of Redistributables be distributed separately.

Appendix 1:
Parts of the Licensed Software that are permitted for
distribution ("Redistributables"):
- The Licensed Software's main and plug-in libraries in
dynamically loaded library / shared object format.

It also says you can install Qt-Win on more than one computer, as long as you're the only one using any of the copies. Also, the software you develop MUST be under an OSI approved Open Source software license, and you have to give it away. I know, I know, that's not a problem for most of us, but just be aware. ;-)

Section 11 says :
11. Copies of Redistributables may only be distributed with
and for the sole purpose of executing Applications
permitted under this Agreement that Licensee has created
using the Licensed Software. Under no circumstances may any
copies of Redistributables be distributed separately.

To make the thing clear, If I have a GPL application.
I have the right to distribute it for the windows plateform
along with the QT.DLL. But I have not the right to distribute
QT.DLL alone.

I think its a very good move by trolltech to bring developers like me to develop in QT.and the contents of the book also look great and specially the content of the CD makes me to buy this book.
regards

I'm going to get the book, but not so I can use it on windows, since I don't have to use windows. Though it may come in handy some time. I'm going to get it because...

* I like having reference material in book form. I can read it when I'm not at my desk.
* I like to show support for the community.
* I'm sure I'll find something good in the book. I seem to get so little time to code that taking this in the reading room is sure to inspire new code. ;-)

It's really great to have resources like this available. Hats off to Jasmin and Mark, Trolltech, Matthias Ettrich, the publishers and everyone who made this possible.

I've purchased the book and gave it a quick first pass, now I am reading it
in more detail.

I am not a professional programmer, nor have I ever programmed
GUIs before. But I have found myself wanting to a program a GUI
in C++ and QT seemed like a good choice. I bought it for Linux
purposes, not windows purposes so I can't comment on the Windows
version that is distributed on CD. Nor can I compare this with
any other book on the QT subject, I haven't read any. I have
looked at books outside the QT realm that have touched upon
C++ and GUI programming and this book fares well.

I like the book because:

(a) It does not try to teach you C++, so it wastes little
of the readers' time before getting to the subject at hand.
It does get one to understand the generic aspects of GUI
programming within the QT context, something I needed since
I am new to the subject. I think some of this might be unavoidable,
if only for the sake of establishing the vocabulary used in QT.

(b) It embraces a clean object oriented style and a philosophy that would
have taken me a long time to figure out on my own without
reading the book. There seems to be a lot of references out there
on the QT library. But learning how to use the library in its intended
way is what a book like this captures. A book such as this will make you
a better user much quicker. Since the authors work for Trolltech, they
probably have information access that advantages its readers.

(c) The language in the book is simple, so are many of the examples.
Instead of spending too much time on specific subject, a clear
overview of many the library capabilities is covered.
I think the uniformity in the QT methodology makes it simple for one
to go beyond the book in terms of QT complexity.

But I think much of what makes the book good is the fact that QT is
an excellent library that is consistent with itself. So that makes
it a hard book to screw up to start with.

I'm a chip designer by trade. So perhaps that clouds my judgement on
how easy QT really is to use. Dealing with ports (slots),
signals, and connections with events in a rigid modular (and
somewaht parallel) way has become second nature to me.

In that sense, don't expect any scientific revelations or engineering
innovations in reading a book such as this. The concepts used in QT are
tried and tested ones. Afterall, the subject of GUIs and C++ is not a new
one. But the book is a good technical reference on QT.

A COMMENT ON QT

A comment falling outside of the book but within the realm of QT:
I am disappointed QT requires preprocessing of the C++. I faill to see
the reason why this is necessary. I sure hope it isn't for reasons of
syntactic sugar. Nor do I think it is for reasons of performance. If
for either of these two reasons, the Trolltech should have studied
what others have done in the area of signalling and C++ in
much more demanding application than GUIs... The only justification
I can think of is that the QT targets embedded systems that often
have C++ compilers that are watered down versions of the language.
But, if that is the case, I would have preferred something that
pre-processes standard C++ into a weaker version of the language
for the purposes of the embedded platform.

I am not a C++ purist (on most days I use a typeless language!),
but I have seen the dire consequences of pre-processing simpler
languages than C++ when the pre-processor does not have the full-fledged properties of a solid compiler parser. Pre-processing problems I've
encountered in the past were very rare, but when they happened, they were
hard to find and serious. Here's hoping I'll never see one with QT.
In the case of QT, I think it also allows for an ambiguity:

If one releases a GPLed QT appplication, can the code released be the
output of the preprocessor? I hope not for legibility reasons that would
defy the GPL, but I don't know that you can't...

As for the complaints about using QString instead of std::string, I can see
why Trolltech wants absolute control on such an important class
to its library given the set of plaforms/uses it must cover. Again, especially
in the embedded area of things. In this case, it's not like a new keyword
is added to the language, it's still C++ and QString looks like a solid
class.

Well, the preprocessor is still from the Qt 1.x days, at this time the compilers weren't as advanced as today (gcc 2.7.1). The trolls held compatibility for very important, so they didn't change this until now. Maybe it will change for 4.0.

Btw. the preprocessor moc actually works really good, I actually never experience problems. The makefiles get a bit more complicated, but qmake helps a lot with this.

Much of what I earlier called a weakness is presented as a strength.
Some of the 5 reasons given go in the opposite direction of what I have
argued (1. syntax matters, 2. precompilers are good,
4. calling performance is not everything), so I won't bore everyone with
rehashing my views. As for point 5 (no limit), I think it is the type
of argument one makes afer the fact of deciding upon preprocessing.
I must admit some of the language in point 5 is beyond my comprehension,
is this some of internal lingo to Trolltech's framework?

I have seen elegant and syntactically clean ways of doing C++ signalling
in other projects. However, I must concede that those signals do take up
more memory. But in those application, execution speed rules the day
eventhough the signal count is still very large. For some reason, I don't
think signal memory consumption from a GUI is that big an issue.
But the argument against that comes down to embedded systems again.
The other fact that I must concede is that the user base I am considering
in my arguments stops at one user. Trolltech probably thinks things out in a
way compatible with the majority of its users, a majority in which I
probably don't belong on the issue of pre-processing.

I can also attest that there are still some development environments that run
on gcc 2.7.1 and will be for quite some time. Such an environment can be
frustrating to the modern C++ programmer. But to address those compilers,
I would have preferred a down translation from standard C++ to their limited
subset.

As previously stated by a few, the moc is very robust. From a pragmatic
standpoint I am willing to accept that as an answer. Afterall C++ itself
was once a very robust preprocessor to C and little more.

QT is the best thing (by far) that I could find when I went through
the list of GUI options I knew about. While I don't agree with some
of the points made, I can see their merits based on the arguments expressed.
And I am not about a pre-processing issue change my mind on my tool of choice.

But the mere fact that such a justification exists on Trolltech web site
indicates that the reservations about pre-processing must be heard often
enough not to be left unanswered. I think it'll be hard to completetly
silence this out, in the end some of it comes to a matter of preferences that
are not always black and white.

"I have seen elegant and syntactically clean ways of doing C++ signalling in other projects. However, I must concede that those signals do take up more memory."

I once did an experiment as part of a STL class where I wrote the same "fake" CD player app in Qt, Boost::signals (a pure template method), and a home grown signal/slot mechanism using templates. All were statically linked. IIRC the numbers correctly, my implementation came out to 16k, Qt's to 28k, and Boost's to 70k. Huge difference! That was with three signal/slot connections of the same signature. Both mine and Boosts would have dramatically risen with additional signatures.

"But the mere fact that such a justification exists on Trolltech web site indicates that the reservations about pre-processing must be heard often enough not to be left unanswered."

When discussing this all on a theoretical base it's easy to forget that languages are actually in use. Most of those who actively use Qt often experienced the advantages of Trolltech's approach first hand already and don't need an explanation anymore, the "justification" is only for those who tend to completly dismiss Qt due to its moc ignoring why it's actually used.

Since Trolltech promotes its toolkit as portable completely without changes in the source code while keeping the choice of compilers, making down translations from standard C++ to their limited subset depending on the the platform availability of certain compiler features, certain additional libraries like std and boost etc. would completely crush the advantage of being portable; and I can't imagine any software project, be it open like KDE or commercial, to actually be interested in the work overhead introduced by having to maintain different platform forks of their code due to different feature sets available on each of them.

Well, one only need to chose a subset that is low level enough so that
one need not cover a whole spectrum of special cases. Something close
to C (or perhaps gcc 2.7.1). In any case, the amount of work to
cover a new platform seems more substantial outside of this from the Aqua/Mac
comments I encountered when making a choice of Qt. Which tells me the number
of platforms covered by Qt is rather finite and manageable.

As for the memory usage reported in the earlier post, those number are
quite large from what previous experience would dictate but it is interesting to see one reported difference.

In any case, the pre-processor is here to stay even in 4.0 it seems.
So its up to me to warm up to that notion, or find an alternative which
can't see. I'm sure I'll forget I'm using the pre-processor
after a few weeks of Qt usage.

As for my question, does anyone know:

When releasing code depending on Qt under the GPL, is it possible to
release the preprocessor output instead of the pre-moc code? I am hoping
there are measures against doing that in the license, is this correct?

IMHO the reason are non-standard-compliant compilers like VC (especially for template support). So moc is required to provide the signal-slot-mechanism.
As the sigc++ project shows there is no need for such a precompiler if you use
a template-proof c++ compiler - and you would get a faster and more type-safe signal-slot-mechanism.

"IMHO the reason are non-standard-compliant compilers like VC (especially for template support)."

I'm confused at your reference of VC as being a non-standard-compliant compiler. As far as I know, which I've been reiterated by many published sources, the current VC++ is the MOST standard-compliant compiler out of any available, ESPECIALLY for template support. Are we talking about the same "VC"?

"I'm confused at your reference of VC as being a non-standard-compliant compiler."

I'm not, but then I'm not using the absolute latest version of Microsoft Bullsh!t Studio. Perhaps the latest output from Microsoft on this front demonstrates their commitment to following standards, just as with all their other products.

Visual Studio.NET 2003 actually seems to have got the templates right. Use ANY other version of Visual Studio (and I mean ANY other) with standard C++ and you're entering a world of pain. Some people don't use the latest and greatest.

I don't really have a problem with preprocessing. But why change the C++ language to add your directives? You could just as easily use C++ macros. Currently a declaration for a Qt class uses extra-C++ member scopes "public slots", "private slots", "protected slots", and "signals". This adds four new categories to the existing "public", "private", and "protected". Why not instead preface the member names with macros like QSIGNAL or QSLOT instead of inventing new keywords and adding new scopes for class members?

I bought it at Amazon.com on 25/01 and i got it last wednesday. Quite fast since it had to cross the Atlantic Ocean. Moreover with a 30% rebate and the euro/$ rate it is quite cheap.
Although i don't have very good knowledge in C++ i think this book is really nice. There is explanation for every line of code they write. Is there any KDE developper to tell us what he thinks about this book from a KDE point of view?

Wasn't there a new book on KDE development in the works? I seem to remember hearing about it.

Anyway the book comes with an older version of Qt, 3.2.1 which won't even let your applications run on 98 or ME if you are using a Borland compiler and on Windows didn't even install correctly even after I followed all the instructions.

Not so much the book, cause I'm already pretty familiar with Qt, but the release of a non-commercial verison of Qt 3 for Windows. It's now possible to port my any apps I write to Windblows! Is this available elsewhere, or only with the book?

I wonder if the majority of this stuff will remain valid, or if it signifies that Qt is planning a radical change in Qt4, as they did with Qt3.

OK, maybe that was a bit of an exaggeration. But when Qt 3 first came out all there was on the Windows Non-commercial side was Qt 2.3, which nobody wanted to use because it was so antiquated. Besides 2.3 not using native widgets, 3.0 introduced an entire new design model that involved ui.h files as opposed to subclasses. That was the radical change I was referring to.

So I've decided to experiment with the Windows version for a short while.
Took me a while to get things installed right, I've not
used Windows much in the past 12 years... Getting the PATH right
required some tinkering and all I could do was reboot on XP.

In any case, when I compile application with non-commercial Qt for Windows,
I get all windows with the title "[Non-Commercial] Application Name"
instead of "Application Name" as in the book. It is a bit annoying...
Is there a way around this or is it a built in feature to the
non-commercial Qt library for Windows?

Those of you debating which Borland compiler to install: when I tried
version 6 it stated the trial would only last 60 days. Could not find
the duration until I went down the path of installing it... User beware.
I was hoping for a feature restricted version instead of a timer...
So I reverted to the 5.5 version, rather slow though.

But hey, it works and it was fun to see all of this on Windows. Now back
to Linux!

Also, will this book be freely availble as a download in a short while?
(in the spirit of open source docs)