I completely agree, and I hope that Corel does solve this problem by distinguishing between their software and sofware developed by other people (including a very small amount by me!).
If they have made changes to code I have contributed then I want to know so that I can merge their changes into CVS.
However before Corel takes this action they must first realize that they are "distributing" software, this is currently the crux of the issue. If they are distributing GPL'd software then they are violating the GPL, they are currently claiming that they are not distributing software.
Hmm, isn't KDE based on the non-free QT libraries, which are in turn QPL'd? (Whatever that means) I don't know if KDE would qualify as free software... Not to worry KDE has always been free software, and the latest version of KDE is based on a free (in FSF sense of the word) version of QT.
I too agree that Matthias deserves to win this award, I know I voted for him!
M2 moderation acts as a disincentive for me to moderate as my karma is (was) over 10.
I have been wondering why my karma has been gravitating towards 10, now that you mention M2 moderation doesn't take someones score outside the -10..10 range I understand why.
Since my karma is (was) over 10 meta-moderation applied to my moderation can only drive my karma down towards 10 (well it tends to oscillate between 9 and 10). When people disagree with my moderation I lose points, when someone agrees with my moderation nothing happens.
Actually I remember on a previous moderation story an AC complainined about their karma rapidly dropping (a few points a day) and that after a week the would hit zero. They wrote back the next day saying that there score seemed to have stopped decreasing, I guess they finally dropped to 10 as well.
I noticed the same thing. The Open Source Definition has an extra clause, 10, that gives examples of licenses that meet the definition.
The other more important difference I noticed is the the OSD specifically prohibits obsfucating the source code (see clause 2), while the DFSG does not.
Leaving us in the rather odd position in which open source software (in the OSD sense) is actually "more free" than "free software" (in the DFSG sense).
The Linux Weekly news article states: The DNSsafe software cannot be used or distributed separately from the BIND software. You only have the right to use it or distribute it as a bundled, integrated product.
which violates several points of the DFSG, in that it restricts distribution of the software;
Surely this is incorrect. If it were correct then it would follow that the QPL license was not DFSG compliant, since the QPL also does not permit distributing any (strict) subset of the QPL'd source code. But this is a contradiction as the QPL has been declared DFSG compliant.
Why not assign an ID to each on anonymous coward on a per story basis? That way it would make it clearer when someone is abusing the system and spamming a story.
Also it would make having coversations with ACs easier. Assign each AC a unique ID the first time the post to a story and kept that ID for the remainder of the story (use the ip address). It would allow people to be anonymous but identifiable.
pmitros: Even if I simply reindent the code to a different style, patch will consider it a completely new program. This is irrelevant the QPL does not require modifications to be created with the diff utility and applied with the patch utility.
pmitros: If I decide to take a file for the "list" widget, copy it over, and modify it to make a "tree" widget, the patch program will also not be able to deal. Again irrelevant the QPL does not require the use of the patch utility.
ac: I've spoken to RMS about this, and he considers QPL not to be completely free, but free enough to be "good enough" for now. I think you are putting words in RMS's mouth, he publicly stated that the QPL was a free software license, I have not seen evidence that he has retracted this statement.
ac:DFSG are guidelines. It's possible to find licenses that fall through the loopholes. Agreed.
ac:This is one Not according to my interpretation or Bruce Perens or the Debian developers
You defined free: ac:I define it to mean it gives me my freedom. Same as RMS. This definition is not useful and it is not the same as RMS, his definition for free is:
http://www.gnu.org/philosophy/free-sw.html
The freedom to run the program, for any purpose (freedom 0).
The freedom to study how the program works, and adapt it to your needs (freedom 1).
The freedom to redistribute copies so you can help your neighbor (freedom 2).
The freedom to improve the program, and release your improvements to the public, so that the whole community benefits. (freedom 3).
I'm still trying to get my head around all the details on this privacy issue. Basically the QPLs stance on privacy is stated in clause 6 of the QPL
6. You may develop application programs, reusable components and other software items that link with the original or modified versions of the Software. These items, when distributed, are subject to the following requirements:
c. If the items are not available to the general public, and the initial developer of the Software requests a copy of the items, then you must supply one.
So in some sense the QPL does protect you privacy. But it doesn't go as far as the GPL, as I stated the GPL allows an organization to freely distribute a modified version of a GPL'd app within that org. I regard this as a flaw in the GPL as it could be used by an unethical company to sidestep the "freedoms" that the GPL is intended to protect.
>It's fine to be more profitable, but not at the >expense of freedom or privacy Interesting statement, normally I think of profit as an economist would, that is taking into account the social costs that production incurs so a company that makes a lot of money dumping toxic waste into a stream wouldn't be profitable at all in my view. By the same logic the loss of freedom/privacy is a social cost and a software company that makes money at the expense of this things is a burden on society.
>The patch clause doesn't really matter because >CVS works that way anyway There are a number of subtleties you are missing here. Firstly I used the term patch clause, but I should point out that, really the phrase "patch clause" referred to the fact that the QPL stated that the 'diff' and 'patch' programs must be used to generate and merge differences. This clause has now been relaxed to requiring modifications to be distributed seperately. Secondly this clause prevents me from taking bits of a QPL'd app and using them myself, something you should be aware of.
We that's a lot of disagreeing I just feel contrary today.
1) The QPL sucks as it is incomptible with the GPL. 2) The QPL sucks as it doesn't protect your privacy. 3) The QPL sucks due to the patch clause.
Or does it?
Yes the GPL may be incompatible with the QPL. In spite of this RMS has stated that the QPL is a free software license, furthermore the QPL is compliant with the Debian Free Software Guidelines.
If the GPL is incompatible with the QPL, that means the GPL is making it difficult to distribute free software, and by extension the FSF is acting against the best interests of software customers by reducing the amount of free software available. Hardly an admirable trait in an organization the claims to support free software, rather they appear to be trying to create a software license monopoly.
Yes,the QPL does not "protect your privacy", but is protecting you privacy not equivalent to reducing the freedoms of software consumers for the benefit of corporations that do not want to share? The privacy loophole in the GPL allows corporations to make their own secret changes to GPL'd source code and not share those changes. Why couldn't an unethical corporation exploit this loophole in the GPL, saying "You can use this software and as a bonus you become a member of my organization, [in small print no you don't get the source we are not required to give it to you under the terms of the GPL]"
Yes the QPL requires source code to be distributed in two parts the original and the modifications. This will benefit the entity that QPLs rather than GPLs their code by making it unlawful for others to borrow bits of source code and by making it more difficult for others to fork the code. It is still legally possible for others to fork the code, it requires software engineering skills rather than being prepared to commit a criminal act.
Nevertheless this characteristic of the QPL suggests an organization will profit more from QPLing rather GPLing their code. Is this "higher profitability of free software companies" really a bad thing? It could act as an incentive encouraging more companies to profitability produce free software.
If it is under the QPL anyone is free to modify the program, recompile, and distribute modified binaries (under reasonable conditions like you have to include a copy of the text of the QPL license).
The distributor must also make available the source code. (In two parts, as an unmodified version of the original code and then seperately the changes that have been made, the redistributor could include a script to merge these two for convenience).
Qt 2 free edition is not available for the Windows platform, or the Mac or Beos or OS/2 or Nextstep or the Commodore 64. QT 2 free edition won't house the homeless or feed the starving.
If Qt 2 free edition was distributed under the GPL or even the LGPL license the situation would be exactly the same.
If you really want QT free edition for windows port it, you are free to do so, however you will have to fork the development as troll tech will not support you.
Well I must be dumb then. The QPL does not discriminate against commercial use anymore than the GPL. I can use QT to run a commercial website (actually you really can QT supports networking). And you could SELL your own QT distribution.
I see no difference between the QPL and the GPL in this regard.
Pages 66-68 of Design and Evolution of C++ by Bjarne Stroustrup (the designer and original implementor of C++) cover this issue.
...there has been a long history of confusion about what Cfront is. It has been called a preprocessor because it generates C, and for people in the C community (and elsewhere) this has been taken as proof that Cfront was a rather simple program - something like a macro preprocessor. People have thus "deduced" (wrongly) that a line-for-line translation from C++ to C is possible that symbolic debugging at the C++ level is impossible when Cfront is used, that code generated by Cfront must be inferior to code generated by "real compilers," that C++ wasn't a "real language," etc. Naturally, I have found such unfounded claims most annoying"
Also see my related posting above on what is a compiler, and in response to the final paragraph I am aware of the concept of a Turing complete language.
Umm... If it reads in C++ and outputs C, how could it be anything but a "preprocessor"? Well, I think we agree CFront is a preprocessor. I am saying it is not just a preprocessor it is also a compiler.
A compiler or translator is a program that translates a file from one language (the source language) into another (the destination language). This is the computer science definition of what a compiler is. You should be able to find it in any good compiler book, and this should be one of the first things taught in a class on compilers.
The destination language need not be the machine language.
A compiler or translator should be able to check that the contents of a file is a valid string in the source language. Because CFront could do this it was (is) a compiler.
This is mentioned in D&E and I have heard Bjarne say it himself in person, in fact the propagation of this fallacy appears to one of his pet peeves.
If it matters I believe g++ was the first native language compiler for unix.
Anything that discriminates against commercial use is PER DEFINITION not Open Source software! Stop bending the rules. So Linux being GPL'd isn't open source software then?
You're either a BSD type license advocate or just plain dumb, I'm guessing the later as you clearly don't know the difference between commercial and proprietary.
Look at most of the good dialogs in an MFC application: there is no need to resize them.
Huh? Ever use windows? The fact is often dialogs benefit from being resizeable, and MFC doesn't support that well. The damn windows find file dialog is the classic example of a dialog that should be resizeable.
Generally any dialog containing a listbox, listview, or (multi)line edit control benefits from being resizeable. Like the multiline edit control I'm typing in now (which isn't resizing with the window)!
Maybe you are used to designing very simple dialogs.
Remember that C++ was simply a preprocessor step for C orginaly
Wrong, this is an often repeated fallacy. The original C++ frontend, CFront, fully parsed the input, it was a compiler (or translator both are equally valid). It did produce C output but that doesn't imply that it was just a preprocessor.
I think this article is baiting us, nevertheless here is my honest response.
Firstly let me say I have nothing against GTK, I have little experience with it, but I constantly hear good things about it, and I've used some very nice GTK based apps.
Personally I choose to use a C++ based library over a C library, (and I'm unimpressed with bindings in general). To give you some idea of where I coming from I have experience with QT and MFC, I use both on a daily basis at the moment, have about a years experience with MFC (spread over 3 years) and about 6 months experience with QT. (I also have about 3 months experience with each of Java AWT, raw WIN32 & WIN16 api programming, and the Harlequin Lisp GUI toolkit).
QT is vastly superior to MFC. By coincidence the free software QT based development I have been doing is similar to (just from a GUI point of view) to the MFC development I have been doing, and this has given me the opportunity to compare the two.
Here are some observations.
Layouts QT has good support for layouts, MFC has none. This means it is much easier to create resizeable dialogs in QT than it is in MFC. This means i18n support is easier in QT than MFC (no need to tweak your dialog for each language you support). I especially like the QT grid layout that supports mutli-cell entries.
Tooltips. Tooltips in MFC are a bit screwed, the MFC CToolTipCtrl isn't useful as is and you have to derive a class from CToolTipCtrl in order to use tooltips. This derivation isn't application specific exactly the same code is need in each app. Why? Quoting programming windows 95 with MFC "Late in the beta cycle, the Windows 95 designers recognized this problem and added some intellignece to tooltip controls so that the designers could do their own subclassing. Unfortunately, this feature was added too late to be incorporated into CToolTipCtrl". MFC programming tends to be like this, every simple little things requires a dozen lines of work before you start doing anything application specific. (There is a very good open source web site www.codeguru.com that has a collection of such code). QT doesn't suffer nearly as severely from this problem, QToolTip::maybetip lets you decide when to show a tooltip, where to put it, and what to put in it, just hook one up to a widget.
Documentation. The documentation that comes (free) with QT is excellent, better than the MFC documentation I have. The 12 stage QT tutorial is excellent compared to say the MFC Scribble tutorial, I get the feeling that QT really is a toolkit whereas MFC is a framework. The QT class documentation has decent see also links (very useful!), and inline example code. Basically it is just of a higher quality than the MFC documentation. The QT source code itself is very readable and is a great source of documentation. (The MFC source code is not so useful)
Signals/Slots The QT toolkit pioneered this concept and it is a good one. Basically they can be used to reduce code coupling and make it easier to create independent components. For high level stuff you don't have to derive a class and override a virtual method with a one line implementation, just connect a signal to slot. People hassle QT for extending the C++ language and this is a valid criticism, however in actual practice this has no drawbacks (you can still debug your programs with gdb and run make to compile all your source). MFC has a signal/slot equivalent "message maps", syntactically they are much uglier.
QTL vs STL I'm all for standards, I really am. Neither MFC nor QT support the STL as a first class citizen. Unforunately there are compelling reasons for this when using (e)gcs. The egcs STL implementation is bloated and slow compared to the QTL. Syntactically the QTL is much simpler (eg container classes expose begin() and end() methods as well as providing external iterator classes). Still if you already know the STL this is an extra thing to learn.
High quality widgets QListView is an awesome control unifying the TreeCtrl and ListCtrl concepts. In general QT widgets are done right.
Basically using QT has helped me understand why people complain so bitterly about MFC, and proven to me that there is a better way.
At one point the article states the Marketing director will be required to eats bugs if any bugs are found in a product, later the article contradicts itself by saying he may be required to eat bugs if a release "requires bug fixes".
I suspect the Marketing director believed he agreed to the later. Developing software with a zero tolerance for bugs is damn expensive. If you disagree you need to read the RAD book.
Slashdot Mirror
I completely agree, and I hope that Corel does solve this problem by distinguishing between their software and sofware developed by other people (including a very small amount by me!).
If they have made changes to code I have contributed then I want to know so that I can merge their changes into CVS.
However before Corel takes this action they must first realize that they are "distributing" software, this is currently the crux of the issue. If they are distributing GPL'd software then they are violating the GPL, they are currently claiming that they are not distributing software.
Hmm, isn't KDE based on the non-free QT libraries, which are in turn QPL'd? (Whatever that means) I don't know if KDE would qualify as free software...
Not to worry KDE has always been free software, and the latest version of KDE is based on a free (in FSF sense of the word) version of QT.
I too agree that Matthias deserves to win this award, I know I voted for him!
M2 moderation acts as a disincentive for me to moderate as my karma is (was) over 10.
I have been wondering why my karma has been gravitating towards 10, now that you mention M2 moderation doesn't take someones score outside the -10..10 range I understand why.
Since my karma is (was) over 10 meta-moderation applied to my moderation can only drive my karma down towards 10 (well it tends to oscillate between 9 and 10). When people disagree with my moderation I lose points, when someone agrees with my moderation nothing happens.
Actually I remember on a previous moderation story an AC complainined about their karma rapidly dropping (a few points a day) and that after a week the would hit zero. They wrote back the next day saying that there score seemed to have stopped decreasing, I guess they finally dropped to 10 as well.
I noticed the same thing. The Open Source Definition has an extra clause, 10, that gives examples of licenses that meet the definition.
The other more important difference I noticed is the the OSD specifically prohibits obsfucating the source code (see clause 2), while the DFSG does not.
Leaving us in the rather odd position in which open source software (in the OSD sense) is actually "more free" than "free software" (in the DFSG sense).
It's a strange world.
The Linux Weekly news article states:
The DNSsafe software cannot be used or distributed separately from the BIND software. You only have the right to use it or distribute it as a bundled, integrated product.
which violates several points of the DFSG, in that it restricts distribution of the software;
Surely this is incorrect. If it were correct then it would follow that the QPL license was not DFSG compliant, since the QPL also does not permit distributing any (strict) subset of the QPL'd source code. But this is a contradiction as the QPL has been declared DFSG compliant.
Why not assign an ID to each on anonymous coward on a per story basis? That way it would make it clearer when someone is abusing the system and spamming a story.
Also it would make having coversations with ACs easier. Assign each AC a unique ID the first time the post to a story and kept that ID for the remainder of the story (use the ip address). It would allow people to be anonymous but identifiable.
pmitros: Even if I simply reindent the code to a different style, patch will consider it a completely new program.
This is irrelevant the QPL does not require modifications to be created with the diff utility and applied with the patch utility.
pmitros: If I decide to take a file for the "list" widget, copy it over, and modify it to make a "tree" widget, the patch program will also not be able to deal.
Again irrelevant the QPL does not require the use of the patch utility.
ac: I've spoken to RMS about this, and he considers QPL not to be completely free, but free enough to be "good enough" for now.
I think you are putting words in RMS's mouth, he publicly stated that the QPL was a free software license, I have not seen evidence that he has retracted this statement.
ac:DFSG are guidelines. It's possible to find licenses that fall through the loopholes.
Agreed.
ac:This is one
Not according to my interpretation or Bruce Perens or the Debian developers
You defined free:
ac:I define it to mean it gives me my freedom. Same as RMS.
This definition is not useful and it is not the same as RMS, his definition for free is:
http://www.gnu.org/philosophy/free-sw.html
The web page you reference is out of date, QT has since been released under the QPL license.
Furthermore you are making up your own definition of free, neither I, nor the Debian Free Software Guidelines nor RMS agree with it.
I'm still trying to get my head around all the details on this privacy issue. Basically the QPLs stance on privacy is stated in clause 6 of the QPL
6. You may develop application programs, reusable components and other software items that link with the original or modified versions of the Software. These items, when distributed, are subject to the following requirements:
c. If the items are not available to the general public, and the initial developer of the Software requests a copy of the items, then you must supply one.
So in some sense the QPL does protect you privacy. But it doesn't go as far as the GPL, as I stated the GPL allows an organization to freely distribute a modified version of a GPL'd app within that org. I regard this as a flaw in the GPL as it could be used by an unethical company to sidestep the "freedoms" that the GPL is intended to protect.
>It's fine to be more profitable, but not at the
>expense of freedom or privacy
Interesting statement, normally I think of profit as an economist would, that is taking into account the social costs that production incurs so a company that makes a lot of money dumping toxic waste into a stream wouldn't be profitable at all in my view. By the same logic the loss of freedom/privacy is a social cost and a software company that makes money at the expense of this things is a burden on society.
>The patch clause doesn't really matter because
>CVS works that way anyway
There are a number of subtleties you are missing here. Firstly I used the term patch clause, but I should point out that, really the phrase "patch clause" referred to the fact that the QPL stated that the 'diff' and 'patch' programs must be used to generate and merge differences. This clause has now been relaxed to requiring modifications to be distributed seperately. Secondly this clause prevents me from taking bits of a QPL'd app and using them myself, something you should be aware of.
We that's a lot of disagreeing I just feel contrary today.
1) The QPL sucks as it is incomptible with the GPL.
2) The QPL sucks as it doesn't protect your privacy.
3) The QPL sucks due to the patch clause.
Or does it?
Yes the GPL may be incompatible with the QPL. In spite of this RMS has stated that the QPL is a free software license, furthermore the QPL is compliant with the Debian Free Software Guidelines.
If the GPL is incompatible with the QPL, that means the GPL is making it difficult to distribute free software, and by extension the FSF is acting against the best interests of software customers by reducing the amount of free software available. Hardly an admirable trait in an organization the claims to support free software, rather they appear to be trying to create a software license monopoly.
Yes,the QPL does not "protect your privacy", but is protecting you privacy not equivalent to reducing the freedoms of software consumers for the benefit of corporations that do not want to share? The privacy loophole in the GPL allows corporations to make their own secret changes to GPL'd source code and not share those changes. Why couldn't an unethical corporation exploit this loophole in the GPL, saying "You can use this software and as a bonus you become a member of my organization, [in small print no you don't get the source we are not required to give it to you under the terms of the GPL]"
Yes the QPL requires source code to be distributed in two parts the original and the modifications. This will benefit the entity that QPLs rather than GPLs their code by making it unlawful for others to borrow bits of source code and by making it more difficult for others to fork the code. It is still legally possible for others to fork the code, it requires software engineering skills rather than being prepared to commit a criminal act.
Nevertheless this characteristic of the QPL suggests an organization will profit more from QPLing rather GPLing their code. Is this "higher profitability of free software companies" really a bad thing? It could act as an incentive encouraging more companies to profitability produce free software.
Why? What advantage does the GPL afford you that the QPL does not?
Source code modifications seperately (with a script to merge them I guess).
Binaries distribution of modifications (the thing everyone wants) is allowed.
If it is under the QPL anyone is free to modify the program, recompile, and distribute modified binaries (under reasonable conditions like you have to include a copy of the text of the QPL license).
The distributor must also make available the source code. (In two parts, as an unmodified version of the original code and then seperately the changes that have been made, the redistributor could include a script to merge these two for convenience).
Basically it is similar to the GPL.
Qt 2 free edition is fully free, not pseudo free.
Qt 2 free edition is not available for the Windows platform, or the Mac or Beos or OS/2 or Nextstep or the Commodore 64. QT 2 free edition won't house the homeless or feed the starving.
If Qt 2 free edition was distributed under the GPL or even the LGPL license the situation would be exactly the same.
If you really want QT free edition for windows port it, you are free to do so, however you will have to fork the development as troll tech will not support you.
Well I must be dumb then. The QPL does not discriminate against commercial use anymore than the GPL. I can use QT to run a commercial website (actually you really can QT supports networking). And you could SELL your own QT distribution.
I see no difference between the QPL and the GPL in this regard.
Pages 66-68 of Design and Evolution of C++ by Bjarne Stroustrup (the designer and original implementor of C++) cover this issue.
...there has been a long history of confusion about what Cfront is. It has been called a preprocessor because it generates C, and for people in the C community (and elsewhere) this has been taken as proof that Cfront was a rather simple program - something like a macro preprocessor. People have thus "deduced" (wrongly) that a line-for-line translation from C++ to C is possible that symbolic debugging at the C++ level is impossible when Cfront is used, that code generated by Cfront must be inferior to code generated by "real compilers," that C++ wasn't a "real language," etc. Naturally, I have found such unfounded claims most annoying"
Also see my related posting above on what is a compiler, and in response to the final paragraph I am aware of the concept of a Turing complete language.
Umm... If it reads in C++ and outputs C, how could it be anything but a "preprocessor"?
Well, I think we agree CFront is a preprocessor. I am saying it is not just a preprocessor it is also a compiler.
A compiler or translator is a program that translates a file from one language (the source language) into another (the destination language). This is the computer science definition of what a compiler is. You should be able to find it in any good compiler book, and this should be one of the first things taught in a class on compilers.
The destination language need not be the machine language.
A compiler or translator should be able to check that the contents of a file is a valid string in the source language. Because CFront could do this it was (is) a compiler.
This is mentioned in D&E and I have heard Bjarne say it himself in person, in fact the propagation of this fallacy appears to one of his pet peeves.
If it matters I believe g++ was the first native language compiler for unix.
Look at The Approved Licenses list http://www.opensource.org/licenses/
item number 7 is the QPL.
Anything that discriminates against commercial use is PER DEFINITION not Open Source software! Stop bending the rules.
So Linux being GPL'd isn't open source software then?
You're either a BSD type license advocate or just plain dumb, I'm guessing the later as you clearly don't know the difference between commercial and proprietary.
Look at most of the good dialogs in an MFC application: there is no need to resize them.
Huh? Ever use windows? The fact is often dialogs benefit from being resizeable, and MFC doesn't support that well. The damn windows find file dialog is the classic example of a dialog that should be resizeable.
Generally any dialog containing a listbox, listview, or (multi)line edit control benefits from being resizeable. Like the multiline edit control I'm typing in now (which isn't resizing with the window)!
Maybe you are used to designing very simple dialogs.
Remember that C++ was simply a preprocessor step for C orginaly
Wrong, this is an often repeated fallacy. The original C++ frontend, CFront, fully parsed the input, it was a compiler (or translator both are equally valid). It did produce C output but that doesn't imply that it was just a preprocessor.
I think this article is baiting us, nevertheless here is my honest response.
Firstly let me say I have nothing against GTK, I have little experience with it, but I constantly hear good things about it, and I've used some very nice GTK based apps.
Personally I choose to use a C++ based library over a C library, (and I'm unimpressed with bindings in general). To give you some idea of where I coming from I have experience with QT and MFC, I use both on a daily basis at the moment, have about a years experience with MFC (spread over 3 years) and about 6 months experience with QT. (I also have about 3 months experience with each of Java AWT, raw WIN32 & WIN16 api programming, and the Harlequin Lisp GUI toolkit).
QT is vastly superior to MFC. By coincidence the free software QT based development I have been doing is similar to (just from a GUI point of view) to the MFC development I have been doing, and this has given me the opportunity to compare the two.
Here are some observations.
Layouts
QT has good support for layouts, MFC has none. This means it is much easier to create resizeable dialogs in QT than it is in MFC. This means i18n support is easier in QT than MFC (no need to tweak your dialog for each language you support).
I especially like the QT grid layout that supports mutli-cell entries.
Tooltips.
Tooltips in MFC are a bit screwed, the MFC CToolTipCtrl isn't useful as is and you have to derive a class from CToolTipCtrl in order to use tooltips. This derivation isn't application specific exactly the same code is need in each app. Why? Quoting programming windows 95 with MFC "Late in the beta cycle, the Windows 95 designers recognized this problem and added some intellignece to tooltip controls so that the designers could do their own subclassing. Unfortunately, this feature was added too late to be incorporated into CToolTipCtrl". MFC programming tends to be like this, every simple little things requires a dozen lines of work before you start doing anything application specific. (There is a very good open source web site www.codeguru.com that has a collection of such code). QT doesn't suffer nearly as severely from this problem, QToolTip::maybetip lets you decide when to show a tooltip, where to put it, and what to put in it, just hook one up to a widget.
Documentation.
The documentation that comes (free) with QT is excellent, better than the MFC documentation I have. The 12 stage QT tutorial is excellent compared to say the MFC Scribble tutorial, I get the feeling that QT really is a toolkit whereas MFC is a framework. The QT class documentation has decent see also links (very useful!), and inline example code. Basically it is just of a higher quality than the MFC documentation. The QT source code itself is very readable and is a great source of documentation. (The MFC source code is not so useful)
Signals/Slots
The QT toolkit pioneered this concept and it is a good one. Basically they can be used to reduce code coupling and make it easier to create independent components. For high level stuff you don't have to derive a class and override a virtual method with a one line implementation, just connect a signal to slot. People hassle QT for extending the C++ language and this is a valid criticism, however in actual practice this has no drawbacks (you can still debug your programs with gdb and run make to compile all your source). MFC has a signal/slot equivalent "message maps", syntactically they are much uglier.
QTL vs STL
I'm all for standards, I really am. Neither MFC nor QT support the STL as a first class citizen. Unforunately there are compelling reasons for this when using (e)gcs. The egcs STL implementation is bloated and slow compared to the QTL. Syntactically the QTL is much simpler (eg container classes expose begin() and end() methods as well as providing external iterator classes). Still if you already know the STL this is an extra thing to learn.
High quality widgets
QListView is an awesome control unifying the TreeCtrl and ListCtrl concepts. In general QT widgets are done right.
Basically using QT has helped me understand why people complain so bitterly about MFC, and proven to me that there is a better way.
Rapid Development : Taming Wild Software Schedules
m er-reviews/1556159005/002-5839722-2382817
by Steve C McConnell
http://www.amazon.com/exec/obidos/ts/book-custo
Even though it's published by Microsoft Press it isn't MS focused or specific. It is easy to read, enjoyable(!) and informative.
At one point the article states the Marketing director will be required to eats bugs if any bugs are found in a product, later the article contradicts itself by saying he may be required to eat bugs if a release "requires bug fixes".
I suspect the Marketing director believed he agreed to the later. Developing software with a zero tolerance for bugs is damn expensive. If you disagree you need to read the RAD book.
Two wrongs don't make a right.