Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

C++ GUI Programming with Qt 4 148

Posted by samzenpus from the read-all-about-it dept.
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.
This discussion has been archived. No new comments can be posted.

C++ GUI Programming with Qt 4 More

C++ GUI Programming with Qt 4

Comments Filter:
  • advanced modal/view functionality
    That's a combination of model/view and modal dialog boxes, is it?

  • Update on the link (Score:1, Informative)

    by Anonymous Coward
    Slashdot has linked to B & N here, but it seems that Amazon has it much cheaper [amazon.com].

    • Re:Update on the link (Score:3, Informative)

      by rm999 ( 775449 )
      And your link doesn't have a referral tag (which I hate because I know those are the next popup windows of the internet).

      It's hard to write a bad review when you know you will make money if people buy it...
    • Bookpool has it even cheaper ($32.95 USD).

  • Interoperability (Score:2, Insightful)

    by lkeagle ( 519176 )
    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.

  • Platform license. (Score:1)

    by Anonymous Coward
    "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 [trolltech.com]

    It also looks like they'll try to squeeze in some cool SVG related stuff. http://zrusin.blogspot.com/ [blogspot.com]

    Man, Qt simply pwns GTK
    • I was never a KDE fan - I always liked Gnome stuff better, until I programmed in Qt for a project at school. After working with Qt I got absolutely sold on it and KDE. I kind of wish that GTK was better than Qt because then I would use it on commercial products, but honestly I'd gladly pay the fee to use Qt.
      • I was never a KDE fan - I always liked Gnome stuff better, until I programmed in Qt ...

        If you don't like coding with GTK for Gnome, why didn't you try wxWidgets?

        O. Wyss
      • If you're only on Linux, then fine. If you need cross-platform support, KDE isn't an option, in spite of it being on top of Qt.

        I still can't understand why a group of apparently intelligent people decided to take Qt, which provides a cross-platform widget set and significant parts of an OS abstraction layer, and use it to build a single-platform setup. If they just wanted a single-platform widget set for Linux, what was wrong with Lesstif or some other free widget set? But taking something built for cros

    • Re:Update for 4.2? (Score:1, Informative)

      by Anonymous Coward
      "Man, Qt simply pwns GTK"

      Yes, I agree, except for one thing. GTK has the nice feature of being able to switch input methods easily without having to install additional keyboard layouts or whatever. As someone who uses the transliterated Cyrillic input method frequently, I wish QT/KDE would add this.
  • > 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?

  • The free edition (Score:2, Insightful)

    by ratta ( 760424 )
    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 :)
    • I thought your project had to be licensed under something GPL compatible. OpenSource.com has a few lists of GPL compatible licenses, btw. So that rules out BSD licensed projects using Qt, as far as I knew.

      • Its not proven in court that you cant dynamic link to anything. And copyright laws are not the same in every country anyway. Anyone big enough for trolltech to notice they exist and sue them would have no problem buying the license anyway.

        The real problem is that, imagine trolltech stop licensing it, or if the distros just fork it. It would be rendered useless for commercial applications. If it were not for gnome it could be a major drawback for linux.

        • imagine trolltech stop licensing it

          http://www.trolltech.com/developer/knowledgebase/1 89/ [trolltech.com]

          or if the distros just fork it

          "The distros" could just as easily fork Gtk. Why is this issue specific to Qt?

          • GTK free license allows comercial software to link to it. Thats not true for QT.

            The dual-licensing used in QT depends on Trolltech being the owner of all of it. Any small change in the gpl version that is not owned by Trolltech will not be able to be licensed for comercial purposes.

            • Now, following the link of the grandparent, I read that there is an agreement that if they cannot continue the KDE Free Qt Foundation is allowed to release a bsd style license for it.

              http://www.kde.org/whatiskde/kdefreeqtfoundation .php

              This foundation is allowed to do that, but they could disappear before Trolltech. Forever is a long time, and I like to think linux will live forever.

              This is probably the biggest advantage linux has over any comercial OS. Microsoft can go bankrupt, but there is no way t

            • GTK free license allows comercial software to link to it. Thats not true for QT.

              That's true, however the licensing of Qt is about as flexible as it can be whilst still allowing Trolltech to continue doing business. It's pretty reasonable if you ask me.

              Any small change in the gpl version that is not owned by Trolltech will not be able to be licensed for comercial purposes.

              Nobody is going to fork the Qt GPL version unless Trolltech start taking it in the wrong direction. Given the nature of Trolltech as a com
        • "If it were not for gnome it could be a major drawback for linux."

          What are you getting at? gnome is already the biggest drawback of Linux for me, and I never even have it on my machines.
  • 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!

    • Re:Qt is very nice. (Score:2, Informative)

      by Almahtar ( 991773 )
      In my senior design class my last year of college, the project was to build a Windows app that did X, Y, and Z - any extra features and polish were left to the students' imaginations. The 3 students that used Qt did substantially better than the others, and their stuff ran on Windows, Mac, and Linux. None of them reported having to change a single line of source code porting from one platform to the next. The 6 Java people didn't do as well as the .net people overall, but their stuff ran on Mac most of t

      • The 6 Java people didn't do as well as the .net people overall, but their stuff ran on Mac most of the time. They reported spending some time and effort to get the Mac version working.

        I call "Shenanigans" on this. I'm not a Java fanboy by any means but I would have to say that if they could not get it to run on Windows, Mac and Linux, then clearly they were not very good coders. The projects I did in Java for my programming classes ran on Windows and Linux with never a problem. My machines were Linux at hom

        • I kid you not. First off, they had problems right off the bat loading large image files. There's some limit to the size of a jpg you can load in Java's standard libraries (at least with default settings), so most of them couldn't load say a 5000x5000 image. Not sure if any of them ever found a workaround for it. I watched 3 other students' final presentations: 2 used Java and 1 used VB.NET. One java guy chose java because he wanted to develop on his Mac and only use Windows machines for testing. He w
    • As someone who's used QT in it's non-free form, I can say that it is the bane of my existance. Trolltech do not provide licenses for a company. They provide developer-locked licenses.

      If someone without a Qt license identifies a change in my code and I am off on a week of leave they are not legally allowed to make the change. Sure, they could log in as me, enter source control as me and do the work. But there is no way in hell I'm giving them my password so that screws all that up.

      It also makes it hard a
  • May I be the first to reccommend http://cartan.cas.suffolk.edu/moin/OopDocbookWiki [suffolk.edu]

    Fine teaching text, so far.

  • Design flaws in QT? (Score:4, Insightful)

    by Anonymous Coward on Monday August 07, 2006 @04:35PM (#15861264)
    Has anyone using the QT API noticed that its behavior when it encounters an error isn't well-defined or easily detectable by the user of the library? For instance, look at QFileInfo's size member function [trolltech.com].

    Returns the file size in bytes, or 0 if the file does not exist or if the size is 0 or if the size cannot be fetched.


    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.

    • Re:Design flaws in QT? (Score:3, Insightful)

      by Jerry ( 6400 )
      I've seen you post this question on QtCentre, too.

      Use QFileInfo::isFile to determine if the file exists, then QFileInfo::size returns the file size in bytes, or 0 or if the size is 0 or if the size cannot be fetched.

      What's so hard about that? You've never run into tri-states before?
      • Returning a negative number for failure would have been better- you don't have to worry wether 0 means an empty file or an error, it would always mean an empty file, and < 0 would always mean an error. You could also then return different negative numbers for different error conditions. It may have a work around, but its a poor design.
        • Returning a negative number for failure would have been better- you don't have to worry wether 0 means an empty file or an error, it would always mean an empty file, and

          If you're talking about C++, you should really be throwing an exception for errors (otherwise known as exceptional conditions). Return codes went out of style a long time ago and are considered poor design when you have alternatives

          • If you're talking about C++, you should really be throwing an exception for errors (otherwise known as exceptional conditions). Return codes went out of style a long time ago and are considered poor design when you have alternatives

            Now, if only I could convince my project lead of that. Had to totally uglify the interface of the component I was working on because I couldn't throw exceptions. Never mind that there was absolutely no way my component could handle any errors.

          • Oh god no. Throwing exceptions is poor style, especially for normal error conditions. Exceptions hould only occur when something totally unpredictable and unrecoverable like out of memory occurs. Exceptions are performance bottlenecks, lead to ugly, verbose code, and spaghetti like error handling. They should never be used for anything that can be anticipated and handled in other manners.
            • "Throwing exceptions is poor style, especially for normal error conditions. Exceptions hould only occur when something totally unpredictable and unrecoverable like out of memory occurs. Exceptions are performance bottlenecks, lead to ugly, verbose code, and spaghetti like error handling. They should never be used for anything that can be anticipated and handled in other manners."

              Bzzzt. Wrong. Thank you for playing.

              Like most dogmatic, arbitrary, rigid, "I have seen the light" rules, this one has poor appli

              • They allow directly handling the exceptional condition at the point best suited to handle it: not necessarily the caller, but maybe several levels above.

                In other words: they allow people to write completely unstructured spaghetti code thats impossible to maintain. ANyone who uses exceptions for this needs to be fired immediately.

                They are an out of band reporting mechanism.

                They're a poor implementation of this. The correct way to handle out of band data is to allow a function to return more than one piece

                • I can understand that you may not be ready to grasp the concepts, but it might be better to either provide supporting logic for your assertions, or else forego making the assertions altogether.

                  If you are going to assert that "exceptions are a language flaw", that flies in the face of widely accepted practice. Just about every serious language of reasonably modern vintage implements them; they are an accepted staple. If you are going to go against overwhelming mainstream thought, you are going to need some
            • Exceptions are performance bottlenecks, lead to ugly, verbose code, and spaghetti like error handling.
              This is complete bullshit.

              In modern C++ Exceptins have nearly zero overhead. And I really can't see why an if (error == code) .... else if () chain is less spaghetti than catch (X x) .... catch (Y y).

              Error Codes are EVIL. Exceptions not.

              angel'o'sphere

        • Returning a negative number for failure would have been better- you don't have to worry wether 0 ltmeans an empty file or an error, it would always mean an empty file, and < 0 would always mean an error. You could also then return different negative numbers for different error conditions. It may have a work around, but its a poor design.

          If you're talking about C++, you should really be throwing an exception for errors (otherwise known as exceptional conditions). Return codes went out of style a long

          • Exceptions are bad for two reasons:
            * they are verbose - I don't want to write by try .. catch blocks all over the place.
            * they are used as a crutch

            Anyway, this is not a design error. If you want to know what the size of a file is, first check that it exists, if it does, open it. Seek to the end and check your position. You are done. It is not a big deal.

            Now I do use exceptions all the time in C++ and Ruby, I just don't want to have exceptions thrown by the library left and righ
        • If only you could just have the source code to something like this, then you can "fix" it just how you like it. Ah well, just a dreamy afternoon for me...
          • Its rather difficult to fix a key system library's interface. It would cause minor problems like, oh, breaking every other program that uses the library. I could submit a change easily, but it would need to be accepted for the next interface revision, and would likely not be accepted until a major revision as it would break all existing clients.

      • Re:Design flaws in QT? (Score:1, Informative)

        by Anonymous Coward
        QFileInfo claims to (and appears to) use caching, so while "i.isFile();i.size()" looks like a race condition, it's really not, right?

        But doesn't getting all the information about a file require more than one call? stat() will get you length and such, but not the value for readLink(), no? So isn't that still a race condition?

        It's not at all obvious from the QFileInfo docs what is atomic, and when you're writing filesystem code that's kind of important.

        (I've written large programs in Qt, and yes, they've ma

      • Re:Design flaws in QT? (Score:3, Informative)

        by bit01 ( 644603 )

        Use QFileInfo::isFile to determine if the file exists, then QFileInfo::size returns the file size in bytes, or 0 or if the size is 0 or if the size cannot be fetched.

        This is buggy. It is a race condition. If the underlying file is deleted or renamed or is replaced by a named pipe in between those two calls the return from both calls is inconsistent.

        This sort of error is unfortunately endemic in GUI code, not just qt, and is a large part of why GUI programs, are often flakey. GUI libraries usually have

        • This sort of error is unfortunately endemic in GUI code

          It's not just limited to GUI code - some bugs in otherwise plain-vanilla multithreaded code are *hard* to track down because a lot of people don't stop to consider that the system can usually switch away from the current thread any damn time it feels like it, and you have to actively take steps to make sure the state you think you're in and the state you are in coincide with each other.

  • 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 somethin

    • Does anybody know what the terms of the closed license actually are?


      Our commercial license cost about $3,300 US for one developer and includes one year of email support and acess to the latest updates and releases at no charge. Which, I should add, is very good.
      With that license you get connectivity to all the major databases, and a license to distribute binaries of your app for either Windows or Linux. In my experience QT is an excellent development library.

      • I'm not trying to stir the pot, and I'm also not a Microsoft fanboy, but what Qt offers for that $3300 absolutely pales in comparison to what you get with a VS 2005 Pro/MSDN Premium subscription for $800 less. I've yet to see anything in the Linux world even approach the quantity, quality, and organization of documentation that MSDN offers. It's almost like trying to drink from a firehose.

        Of course with MSDN you're limited to Windows, but on the other hand there's plenty of stuff Qt doesn't abstract fo

        • I'm not trying to stir the pot, and I'm also not a Microsoft fanboy, but what Qt offers for that $3300 absolutely pales in comparison to what you get with a VS 2005 Pro/MSDN Premium subscription for $800 less.
          I can't second that. MSDN is often vague, outdated or has no support to known issues at all.

          $3300 is only about 3 to 4 days of a developers sallary and extra costs like housing, insurrances etc. So if a developer saves 3 or 4 days per year with using a better API and tool chain it easy pays off.

          angel'o
    • I'd argue that it's improbable you'd write for windows and not spend a penny. Sure, you can develop .NET applications with nothing more than notepad and the command line, but it'd be a lot like building a 10 story card castle.
      • The "Express" versions of the .net programming tools are free, and they are complete-enough to write full applications with. As far as I'm aware, there are no restrictions whatsoever on applications you write with (say) VB.net Express.

        Now, the "Express" versions are missing some things, so you're correct in that developing with them would be harder than with the commercial versions, but it is certainly possible and a ton easier than Notepad.exe.
    • Simple - you learn on the free version. If you are good enough you can then go commercial with a completely closed application and make money - but you have to feed the people who work at troll a bit too with some of this in the form of a licencing fee. If you are not sure it is good enough or you don't want to go through the hassle of convincing people to buy your stuff you release a completely open application. There is too much crap shareware in the world already - even if you write a gem how will peo
  • 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.
    • Of course. Skype is written in Qt (not sure if its Qt3 or Qt4 off the top of my head), Kopete is a KDE IM app similar to Gaim that is written using Qt/KDE, Psi is a Jabber client, I think GTalk is also written in Qt.

      Lots of programs already use Qt (including Google Earth, and Opera).
    • It wouldn't be so eaasy to redo GAIM or Gimp in Qt. What you can do to force the essential features of GUI programming differs from what is considered good practice in C++. Besides, the Qt applications are often KDE-oriented, and it makes no sense not to leverage that framework when you can, and get a more consistent, interoperating environment. So, instead of rewrites, you have Kopete and Krita. Sometimes programming libraries get shared, as with Beagle, but that's about it.

      I'm more of a C++ and Python

    • Not to stir anything up, but how does Qt compare to GTK?

      API-wise, Qt is far superior. GTK is a horrible API, and requires way too much typing to get anything done. Qt is a nice, clean C++-based API that's pretty nice to use. The upside of GTK is that it's much easier to use from non-C++ languages*.

      From an end-user standpoint, GTK is pretty decent. I'm not sure I see the benefit in rewriting a GTK app in Qt, or vice versa.

      * Before anyone gets bent out of shape, I've been using both toolkits for a

  • 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 Pytho

    • If this is what you want, you're better off using Boost [boost.org] than Qt. The GUI library is what makes Qt great. If you just want a foundation library for smart pointers, signals/slots, containers, threads and a bunch of stuff that it never occurred to you that you might need, Boost is far, far superior.

      Not only is Boost exception-safe (which almost none of Qt is), but today's Boost library is tomorrow's C++ standard library. Boost prepares you for the future.

  • The Linux desktop would be further along if QT were LGPL instead of GPL. Requiring a multi-thousand dollar license is fine for anything besides platform software, which is why QT can never be incorporated as a core Linux platform library (like glibc).

    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 in

    • If you can't release the source code, I'd rather you didn't release the executable code, either. I'd also rather you can't use Qt in that case, because then you have to put up with awful Windows API crap.
    • I'm probably going ot get modded troll, too, but oh well.

      I can't speak for the academic stuff, but there's a grandchild of your post that does it well enough, I think.

      As for the GPL/LGPL... I definitely agree. Free software licenses should be about freedom. GPL -forces- you to GPL your code, too, and that limits my freedom.

      I was reading the summary right up until I read the part that states the free version requires your app/game/whatever to be GPL. I know that's just standard GPL stuff, but it's not ac

  • 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.

    • 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 st

      • Are you telling me that I can't pass values between Qt classes and those written by others?

        The problem is that you can't throw an exception through Qt, or Qt will leak resources (most likely memory). If you want to use any library that throws exceptions (this includes the standard library; even allocating memory in C++ may throw an exception), and you want to do something with the exception other than abort the program, then at the very least you need to insulate Qt from the exception.

        The situation is

  • QT licensing problems (Score:3, Interesting)

    by pkphilip ( 6861 ) on Tuesday August 08, 2006 @07:12AM (#15864756)
    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.

Slashdot Top Deals

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Close