C++ GUI Programming with Qt 3 217
C++ GUI Programming with Qt 3 | |
author | Jasmin Blanchette, Mark Summerfield |
pages | 464 |
publisher | Prentice Hall |
rating | 9 |
reviewer | Bill Lorenz |
ISBN | 0131240722 |
summary | A smooth introduction to best practices for Qt 3 application development. |
I didn't have to force myself to read this one: the book grabbed my interest from the beginning. It's filled with just enough technical details to whet my technical curiosity, keep me turning pages, and provide the important information, clearly and concisely. I don't have much Qt development experience (none at all yet), although I am experienced in other windowing toolkits. The book quickly provided me with everything I need to know to get up and developing an application, and now I know where to quickly start.
Who's it for?
I am of course a novice Qt developer, yet one with a fair amount of IT experience, specifically with other windowing toolkits. I found this book not only a great introduction for those who want to get started with Qt, but it's also a trove of information for somewhat intermediate Qt developers. It's not for people who work for Trolltech or have already been developing feature-rich KDE applications; however, besides providing a great point of entry for new Qt developers, the book does touch on some more advanced topics. Technical books tend to age quickly, but I should note that the book is written by some of the people who brought us Qt 3 and are working on bringing us Qt 4, so this book should have a degree of forward compatibility.What can I expect to learn?
The book is divided into two sections: "Basic Qt" and "Intermediate Qt" development.
The basic Qt section covers everything that someone new to Qt would probably want to learn, beginning with a simple application and an explanation of signals and slots (signals and slots work much the same way as windowing events in Java, for example, and can help to tell when a button or key is pressed). Signals and slots help make the sample application functional. This section also introduces the Qt reference documentation, available online as a reference during development, and Qt Designer, for those who want to use a graphical user interface to create components such as dialog boxes. A quick overview of some of the available widgets is next (widgets are graphical elements such as dialog boxes and buttons), which helps to give someone brand new to Qt development a feel for some of the components that come ready-to-build-upon. This is all covered in the first 38 pages of the book.
I should point out that I think that knowledge of the C++ programming language is essential if one is to learn good things from this book (I'm a big proponent of learning through experience, and you'll need to play with C++ code), but learning Qt and C++ development at the same time might help one come up with some interesting project ideas for learning!
After a quick introduction to creating custom widgets and double buffering (used in some cases to prevent screen flicker), the intermediate section starts by hopping right into layout managers, intended to make graphical forms and components beautiful (and more usable), just like tables helped to make HTML beautiful before CSS came around; layout managers help do for graphical application components what the font and alignment settings do for a word processor. The managers included are very similar to those used in Java's JFC/Swing stuff, and they work well. Also covered are methods for creating 2D and 3D graphics, drag-and-drop, and event processing. Compared to signals and slots, event processing gives the developer more control, and becomes important when writing custom widgets or changing the way an existing widget behaves.
Following this are sections on internationalization, providing online help within an application, multithreading for responsive applications, and Qt's platform-specific features. Qt works with Microsoft's ActiveX, for example, although this apparently requires the Qt/Windows Enterprise Edition as opposed to the free edition of Qt. It's important to point out that Qt implements its own threading capabilities, and the section on threads covers this in depth.
Conclusion
This is a great book for those interested in Qt and KDE development, cross-platform C++ graphical application development, and just making beautiful, functional applications. The book provides information that can't be had from the Qt API alone, and it does so in a way that kept me turning pages. Blanchette and Summerfield organized their text well, with logical chapters that make finding tips for that first application possible. This book gets twelve thumbs up from me.
Bill Lorenz is Vice-President of the Linux Users Group of Cleveland and is helping to organize the Ohio LinuxFest, 2004 edition (call for submissions now in the wild!). You can purchase C++ GUI Programming with Qt 3 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Why to get this book (Score:5, Informative)
The book comes with a free non-commercial version of the QT-Win( windows ) library ( QT 3.3.1, I believe ). The last time this was available was version 2.3.0, so if you want to get a non-expiring version for Windows, here is your chance.
I also read the book is released under a special copyright license similar to the GPL ( the Perens License ), so that after a few months the electronic format of the book becomes legally distributable. Is that cool, or what?
online tutorials (Score:2, Informative)
What you really, really should do... (Score:3, Interesting)
Re:Why to get this book (Score:5, Informative)
Yes. It's the Open Content License. It applies to the printed version today, meaning that you can shove it in a copier if you want and sell the copy, and it will apply to the electronic version when that is released. We usually do that about 3 months after the books reach store shelves. Source and unencrypted PDF will be available as usual.
Unfortunately, I can't say the same for the CD. There is some proprietary software on the CD, I think a Windows version of Qt and some Borland stuff, which isn't really in line with the series policy. But I found out so late that it would have seriously messed things up for the Trolltech folks for me to insist on changes, so I let that go by this time (and made sure it would not happen again).
Next books: Understanding the Linux Virtual Memory Manager [informit.com] next month, and Samba 3 by Example [informit.com] next week! Those are books 9 and 10 in the series.
Thanks
Bruce
Re:Source of the books (Score:3, Informative)
Thanks
Bruce
Re:Source of the books (Score:2)
Thanks
Bruce
Re:Why to get this book (Score:2)
Yeah. Well, it wasn't so much trashing Qt as picking one GUI. And I came in for a good deal of trashing myself.
Qt is Free Software. No question about that. UserLinux has an even higher standard. The application libraries have to be directly usable in proprietary software without another license.
You know, we made another choice. PostgreSQL over MySQL. And we didn't get abused about t
Re:Why to get this book (Score:2)
I've ported my app cubetest [vandenoever.info] to windows with the Builder 5 compiler. This compiler is however very old and the debugger works in DOS. That's not really a problem if the app would work well. Unfortunately, on other computers than my own the app seems to crash quite often eve
Pricing (Score:4, Insightful)
Re:Pricing (Score:3)
Re:Pricing (Score:3, Informative)
Re:Pricing (Score:2)
Re:Pricing (Score:2)
Re:Pricing (Score:2)
Re:Pricing (Score:4, Informative)
It's layers on layers of API's which just multiplies the complexity, amplifies bugs, and slows things down. Not to mention the bloat on bloat.
Plus it's not really very cross platform, there are so many "This works on Gtk but not Windows" or "This works on Windows but not anything else", etc. Your code turns into #ifdef spaghetti hell. You might as well write native versions for each platform.
The only truely viable cross platform (X11, Windows, MacOS) toolkits are:
1. Qt (*too expensive, nice API, kinda bloated/slow)
2. Fltk (tight/fast, nice API, *limited power, ugly/no themes yet)... My current favorite but I have a lot of custom code to make it look good and add features I need.
3. Tk (*horrible API, not very flexible, can be slow)... I haven't used it much because the API sucks. Does this run under an X11 layer or native on MacOS?
4. Gtk (C based painful API or Gtkmm C++ bloat, kinda bloated but relatively fast on X11, slow on Windows, MacOS uses X11 layer, *buggy as hell)
Re:Pricing (Score:2)
Re:Check out Gnome/GTK+ -- WAS Re:Pricing (Score:2)
Just last week people were saying Gnome/GTK+ was truly "free software" because it was under the LGPL, while Qt was under the business-unfriendly GPL. Sheesh, you can't duck out for a minute in this community, or you'll miss the latest marching orders!
It's LGPL (Score:2)
GPL Version (Score:5, Interesting)
Re:GPL Version (Score:2, Informative)
Take a look at MySQL [mysql.com] to see how something can be offered both commercially and under the GPL.
If you are the copyright holder for the entire code, you can license it however you please. The GPL does not remove the right of the copyright holder to do whatever they want with their own code
Re:GPL Version (Score:3, Informative)
Re:GPL Version (Score:2)
Actually you can't modify the GPL. The FSF was smart enough to see confusion like this, so the GPL itself is copyrighted - thou shant make derivative licenses. Different license with similar terms? Sure. Modified GPL - not.
Re:GPL Version (Score:2, Interesting)
Re:GPL Version (Score:3)
Doesn't work that way. The GPL explicitly permits your licensee (who in this case is not a commercial entity if you refuse) to give out the source code to anybody. If you additionally require your licensees not to give it to a commercial entity (which is legal), then it's no longer GPL.
Re:GPL Version (Score:2)
Re:GPL Version (Score:2)
The GPL isn't sustainable through IPC because if it were, Photoshop would be violating the GPL because it can read picture files that were created with the Gimp, for example.
Re:GPL Version (Score:2)
Re:GPL Version (Score:3)
Re:GPL Version (Score:2)
Re:GPL Version (Score:2)
Re:GPL Version (Score:5, Informative)
If you want to develop closed-source applications with QT you need to purchase the commercial version of QT, you can't use the GPL version.
This way of doing things is compatible with the GPL.
Re:GPL Version (Score:5, Informative)
Re:GPL Version (Score:2)
Thats because it isn't (Score:2)
You can sell KDE (example: most commercial Linux distributions.) You can sell GPL Qt applications.
Nothing to see here. Move on folks.
It's a complete fuck-up. (Score:2)
There's QT/Windows non-commercial, which is included with the book.
There's QT/X11 & QT/Windows commercial (for making closed-source apps), which are not included with the book.
Any clearer now?
Kjella
Re:GPL Version (Score:2)
You're correct, and the reviewer was confused. There is a GPL version, with which you can write GPL programs, whether commercial or not. However, if you want to write proprietary programs, not licensed under the GPL, then you need to pay them for a different license.
Also note that there are actually four versions of QT - for QT X11, QT Embedded, QT Mac, and QT Win32. While you should be able to consider them as equivelant when you're writing the code, you'll need the appropriate one to compile the code on
wow! we are at the python/java/.NET era! (Score:4, Funny)
programming GUI in C++... it's so nineties!!
Re:wow! we are at the python/java/.NET era! (Score:3, Funny)
Re:wow! we are at the python/java/.NET era! (Score:3, Insightful)
While for software engineers you might be able to argue that its their field, learn the language, you can't do that with people who use programming as part of their job, but not their main focus. I am constantly faced with the problem of either having other people understand my code, or writing things faster and with less bugs.
The bi
Re:wow! we are at the python/java/.NET era! (Score:2)
Still don't see how I wasn't on topic.
The great thing with Qt: Write once,... (Score:5, Funny)
...review everywhere! [slashdot.org]
C++ Skill... (Score:4, Interesting)
Re:C++ Skill... (Score:5, Informative)
I was in a similar position, with enough self-taught C++ to read and follow code but with no clue of how to build a meaningful GUI app. The great thing about Qt is that it genuinely makes OOP seem logical, in the way you make a bunch of objects and hook them together. I'd greatly recommend getting a free version of Qt, going through the tutorials and examples (that's the other great thing -- the documentation is superb) and maybe then trying KDevelop and the KDE libraries.
Pardon me for gushing, but the combination of Qt and KDevelop was a truly empowering tool in my hands and I strongly recommend it to anyone in the same boat.
Re:C++ Skill... (Score:3, Informative)
Actually, I'd recommend that if he has KDevelop 3, he should use it to create a new Qt app--specifically, the one with the menus/toolbars/text editor. Why? It'll generate a good amount of code, specifically, it'll create a bare-bones text editor. He can then look through the code, compile and run the app, and see how it works, then playing around with it and making changes, seeing how those changes affect the app.
Pardon me for gushing, but the combin
Re:C++ Skill... (Score:2)
It's not a big deal to have to use Linux... but Windows would be more convenient, since that's where I am most of the time.
Re:C++ Skill... (Score:2, Informative)
Re:C++ Skill... (Score:2)
Re:C++ Skill... (Score:2)
I'm guessing that you would have a basic understanding of most of the features of C++ and would understand the philosophy of OOP. The major step is now getting out of a command line user input/system output frame of mind to a GUI one. But startin
Re:C++ Skill... (Score:2)
Re:C++ Skill... (Score:2)
Re:C++ Skill... (Score:3, Informative)
Signals and slots are probably the biggest hurtle to jump over for basic application development in Qt. They're somewhat different than run of the mill callbacks. The event-driven programming paradigm takes a bit of getting used to.
My advice to you, however, is to learn more language
/s/non-commercial/non-proprietary (Score:5, Informative)
What it can't be is proprietary.
I know Slashdot is not known for precision, but on an issue that gets everyone so worked up it's foolish to provoke people like this for no good reason.
Re:/s/non-commercial/non-proprietary (Score:2)
Somewhat OT: Something smaller than Qt3? (Score:3, Interesting)
Qt/Embedded can be configured to for ROM requirements between 800k and 3M, depending on what features are enabled.
I'm working on a new software load for the Ceiva (ver 2), and 800k ROM just for the graphics is way to heavyweight.
800k ROM just for the graphics (Score:2)
Now, yeah, if you only have 400k then you don't want QT. You want something that's much lighter and has fewer features. But that's the nature of embedded programming and something that people who've never done it understand. You're highly constrained by the platform. Just as we were back in the day when 640k was all you had for os, code, and data on a 16 bit platform.
preview is my friend... (Score:2)
arrgh.
Re:800k ROM just for the graphics (Score:2)
How does Qt programming compare with Gnustep? (Score:2, Interesting)
Re:How does Qt programming compare with Gnustep? (Score:3, Interesting)
Re:How does Qt programming compare with Gnustep? (Score:2)
er.. make that C++/QT or in my experience Java/Swing
Where's VB for unix (Score:5, Interesting)
Whatever happen to that?
Re:Where's VB for unix (Score:2)
wxWidgets - fully free Qt alternative (Score:5, Interesting)
Now, with the new partnership between wxWidgets and Borland, wxWidgets is likely to develop even more rapidly.
Though wxWindows is free, unlike the free version of Qt it is not GPL, thus it can be used for commercial software development without worry.
Re:wxWidgets - fully free Qt alternative (Score:3, Interesting)
1) WxWindows break OO principles by using message maps; in other words, you don't overload a method, you define which callback to call using an id through a table. Message maps is a major reason why MFC sucks.
2) There are quite a few bugs in it.
In my opinion, not everything should be without price. Since Qt is the best toolkit there is, Trolltech deserves to get rich (hey, even BillG got rich from the horrible kludge that is WIN32).
Re:wxWidgets - fully free Qt alternative (Score:2, Insightful)
> maps; in other words, you don't overload a method,
> you define which callback to call using an id
> through a table. Message maps is a major reason
> why MFC sucks.
You have two choices with respect to connecting events to event handlers in wxWidgets:
1. Use the aforementioned MFC-style message maps.
2. Use the Gtk/Qt signal/slot-style wxEvtHandler::Connect() method.
MFC-style message maps are more prevalent in the documentation, however. Bu
Re:wxWidgets - fully free Qt alternative (Score:4, Informative)
Use the Gtk/Qt signal/slot-style wxEvtHandler::Connect()
Qt's Signals and Slots and wxEvtHandler::Connect() are two entirely different things:
wxWindows requires connection to have a valid id number, which means a mess of ids in the first place. Qt's signals and slots does not require ids. Keeping track of ids is a nightmare, especially if you delete some.
wxWindows connects functions to events, not methods to methods. With wxWindows, can't call an object method directly.
Can't call private methods unless callback function is made friend to a class; which means callback function is visible to end-user (i.e. non-static).
wxEvtHandler::Connect() is not typesafe: any wxObject-derived instance can be passed as user data. Qt's signals and slots and GTK's templated signals are much safer.
Only events can be connected in WxWindows; which means you have to define event data structures, event ids, etc. In Qt, it could not be simpler: connect a method marked as signal to a method marked as slot.
Using Connect() does not mean there are no message maps. In fact, all Connect() does is create a message map dynamically. Which means lots of wasted memory, memory fragmentation etc., slow execution etc
Connect() callbacks accepts specific arguments; Qt's signals and slots accept any argument, just like a normal C++ function.
Can you still claim that wxWindows are equivalent to Qt ? the callback task is much more time-consuming in wxWindows than in Qt. With Qt's signals and slots, one can make beautiful Model-View-Controller architectures; can't say the same with WxWindows.
The Independent Qt Tutorial (Score:2, Informative)
http://www.digitalfanatics.org/project
(but without those spaces in the URL)
Going back / forth GTK and QT (Score:2)
I'm not really interested in commercial application development - just learning.
Re:Online Books (Score:5, Informative)
QT Tutorial [trolltech.com]
Re:Online Books (Score:2)
Re:Sounds like I need it. (Score:4, Informative)
A downside to QT is that it is not free under windows. While this might be okay with companies, if you ever considered writing crossplatform OSS programs, this can hamper things. There is a project [sourceforge.net] porting the X11 version to windows, so its not a complete roadblock..
Of course there is always GTK which has been known to also run under windows [gimp.org] and OS X [sourceforge.net]. It is not my intention to start any flamewars -- I am just pointing out that for those in favour of either toolkit there is plenty of crossplatformability.
If either TK holds any major advantage its that GTK+ natively supports C code, but also has C++ bindings [gtkmm.org]. The signalmm library that came out of gtkmm is actually really nice, and usable for other projects. However, in that case don't forget about boost [boost.org], which also contains a signal library [boost.org], not to mention a *really* nice interface to python [boost.org] (which I'm currently using in a project). Just be warned, you need a fast computer for compiling.
Re:Sounds like I need it. (Score:4, Interesting)
My current thoughts are using Qt/Java or Qt-Ruby, but it will largely depend what I decide to write.
There are also C bindings for Qt in development, if I was going for an extremely simple application I would just use those.
The #1 reason I would learn Qt, however, is to give myself a decent chance of contributing to the Psi project. I would be forced to learn C++ in that case but at least Psi's C++ is clean compared to many C++ apps I've seen. :-)
Some reasons to use an OS' native toolkit (Score:5, Interesting)
I used to be a big fan of cross-platform GUI programming, but having worked on all variations of Windows, Linux desktops, and Mac OS X, I am now against the idea. I now believe if you're going to support a platform, use the native toolkits as they bring a level of consistency that is just not there with cross-platform toolkits. Having to use a GTK or QT-based app on Mac OS X these days proves to be tremendously frustrating. Text boxes don't have spell-checking or auto-completion. The red dot in the window decoration does not change if the document does. In fact, there is often no document-based implementation whereas there would be one if a native solution was developed. On Windows and Linux, the differences may only be cosmetic, but on OSes such as Mac OS X looks are only the tip of the iceberg with the problem. Cocoa widgets look pretty, but they also bring with them a lot of functionality that I've yet to see replicated on these cross-platform toolkits.
So please, when in Rome do as the Romans do.
Re:Some reasons to use an OS' native toolkit (Score:3, Interesting)
The thing is, on a whole class of platforms, Qt is the "native" toolkit.
But you're right. Spell checking isn't only a problem on OSX, it's even a problem on KDE. Even if every KDE app you own uses the built-in spellchecker to check every text entry box, a Qt app you compile today will not use it automatically.
Cross-platform toolkits like wxWindows are supposed to deal with this sort of problem by just proxying the native toolkits. I'm not sure how well this works because I haven't used wx* either, most
Re:Some reasons to use an OS' native toolkit (Score:2)
Re:Some reasons to use an OS' native toolkit (Score:2)
But when I came to mac I realized these toolkits are skin deep only, and you're absolutely right: on mac, at least, there's so much more than the appearance. There's *RICH* MVC, there's services
Re:Sounds like I need it. (Score:5, Insightful)
Re:Sounds like I need it. (Score:2, Informative)
Furthermore, we discussed crossplatform GUI toolkits before here [slashdot.org] and here [slashdot.org]
Cheers,
Ilker
Re:Sounds like I need it. (Score:2)
Just chipping in, I agree with your post
Re:Sounds like I need it. (Score:2)
What really put me off Qt was the MONEY! $1550 for a license may be OK for a company, but that's a serious wad of cash for one person to shell out. And I think it's the dumbest thing in the world to choose a multiplatform toolkit where multiplatform support is too expensive to use!
That's what I've never understood about KDE. I
Re:Sounds like I need it. (Score:3, Insightful)
Re:Sounds like I need it. (Score:2, Interesting)
Ugly is in the eye of the beholder.
Re:Sounds like I need it. (Score:2, Interesting)
The number one thing that confuses newbies
no exception
An incredibly difficult thing to get right no matter how simple the syntax. Exception "tarpits" are very sticky indeed.
home-grown String class
Only because the C++ string class is so limited without the use of STL algorithms.
weird non-standard signal/slot extension
Or you could use the weird "standard" signal/slot mechanism of libsig++. But beware of huge template bloat if you do. Signals/slots are an elegant solution that
I agree (Score:2)
Yet if you need to drop out of the Qt system for speed or some other reason, you can start doing your own memory allocation, pointers and whatnot. All the (ugly) power of C++, all the higher-level encapsulation of Qt, with one language syntax, one IDE (KDevelop 3 is n
Re:Sounds like I need it. (Score:3, Informative)
I greatly prefer Qt to Swing, though. Swing tries to be way to "pure" and as a result can be somewhat contorted.
Re:Sounds like I need it. (Score:2)
For anyone who doesn't want to "ignore the C++ nature of it," I would also recommend looking at gtkmm [gtkmm.org], a class library built upon GTK+ [gtk.org]. I've used it in a couple of projects so far and have generally had a pleasant experience.
Re:Qt is not my favorite toolkit (Score:5, Insightful)
Agh! Xlib and Win32 are horrible GUI APIs! At least Xlib isn't largely at fault --- its not meant to be a full GUI API. Win32, however, has no excuse! Are you honestly telling me you think that Win32 (with its 200 line GUI hello world), is more sensical than Qt???
It is considerably easier to thread a program that does not have a GUI wrapped up inside of a object than one that does not.
Not really. Multi-threading fits pretty naturally with OOP. Look at the BeOS API (which has a lot of parallels with Qt) sometime. Could you give more detail on why you think this is the case?
Object orientation brings bloat: often students would go way overboard in designing a solution, using 30 classes where 5 would suffice.
That's because students, by and large, are stupid. That's why they are in school, to learn. You should have taught them to only use classes when they naturally fall out of the design of the program.
Compilers are not good at OO: compared to C, C++ compilers are immature and buggy.
That was true for the STL and templates, but Qt doesn't use the STL. Qt was very well supported on the compilers of the time. Again, specific examples?
Thankfully, the GTK+ toolkit is winning the battle of the GUI toolkits.
Really now? Seems pretty even to me.
Students these days feel much more grounded in reality when they see their favourite applications such as mozilla, gaim, xchat, and xmms using the same toolkit they do.
Bah! My favorite apps (Konqueror, Kopete, Ksirc, and Amarok) use my favorite toolkit (Qt).
Re:Qt is not my favorite toolkit (Score:5, Insightful)
You were their teacher? Guess who's fault this is.
Re:Qt is not my favorite toolkit (Score:4, Insightful)
I don't know what it is that you're calling a message, but the MacOS X (previously NextStep) api (around since 1989, yes with an eight) has been using method calls (termed messages on objc) since the early days.
Most GUI programming environments work through some form of callbacks. Qt is no exception, though signals and slots are sort of like callbacks on steroids (and definitely more akin to the messages in the NS api than anyhting else, again, your usage of messages is somewhere between narrow and uninformed)...GTK also has callbacks, as does Tkinter, both which have been around.
Today's C++ compilers are generally nearly as fast and stable as their C counterparts. Seriously, they've been stable since at least 1999, and the good ones were stable before that. Qt deliberately created moc and avoided the STL to dodge the sketchy C++ issues of the early days so it was never much of an issue. Quite frankly you should be making the compiler choice for your students and suggesting that they work in a campus lab set up for it if they don't feel like dealing with compiler issues. You should be able to test an environment before they do. As the teacher of the course that is your responsibility.
GTK+ is in no way winning. Qt is a much much cleaner implementation of GUI (somewhat comparable to the object oriented GTK wrappers, except it also provides the foundation classes that GTK lacks). Qt is also a win for portability as it provides a common layer for a large range of functionalities from networking to GUI to openGL across the three major platforms. Last time I checked, gtk2 for windows was less than perfect and a native gtk2 port for mac os X is not even on the horizon yet. is Gnome very popular? yes. is KDE? yes. They're both out there and they're both up there. Just cause you prefer gnome doesn't mean that it's time to declare a winner.
You're making some awfully harsh statements here that appear to have no real backing. Yes you tried to teach Qt and failed. perhaps the student's weren't ready for it? perhaps your campus computing environment wasn't ready for it? perhaps you weren't prepared to teach it? I wouldn't go blaming the GUI toolkit first thing.
Brian
Re:Qt is not my favorite toolkit (Score:4, Insightful)
Because you are a coward?
How awfully nice for you. May we therefore assume that you're more clever than the rest of us?
Qt uses messages. Did you really use Qt or are you making this up?
What makes it easier to thread a program that does not 'have a GUI wrapped up inside of an object' [sic]?
What is so terrible about having a large number of classes? Only the most novice (OO) programmers I've met shy away from creating more than the 'bare minimum' of classes.
What does this have to do with Qt, anyway?
This is plain wrong. There are some great C++ compilers out there and some servicable ones. Intel's C++ compiler and GNU G++ are examples of the former, Microsoft's of the latter. Why did you let students choose their own compiler?
That first sentence is flamebait; the second is inaccurate. Mozilla isn't built on GTK+: perhaps you meant Firefox?
The parent post smells funny. I call shenanigans.
Rik
Re:Qt is not my favorite toolkit (Score:2, Interesting)
Second, if your students over-design, maybe you're doing something wrong as a teacher? I'm a research fellow at a German university and teach students myself. It's true, it takes a while for th
Re:So, if I understood correctly..... (Score:3, Interesting)
C++ is *the* language, complex - sure enough, misunderstood - even more sure, 90% of today's CS stuff is drawned in its own mediocricy - count on that!!! this [josuttis.com] was one of the best books on programming languages I've ever read and if you're capable of understanding 50% of it you're sure to change your opinion on the language. Oh and...
Yes, as well as C, Lisp, Java, PHP...etc. And for all those cases I found the followin
blah blah blah (Score:2)
The point is C++ introduces a ridiculous maount of complexity which its syntax does not handle very well. This is why C is still far more widely used after a decade of C++ advocacy - it is a better language for systems/library/platform development.
Once again, I wholly support any efforts by my competitors to recode in C++. In a year when they are mired in debugging hell, I will have already cashed
Re:Gah! Kill Qt already! (Score:4, Insightful)
With GPL code, you pay for that time/money by giving back to the comunity that provided for you.
With $2400 you pay for that time money by giving back to the comunity that provided for you.
By paying nothing you basically take from the community and ask them to give you money back before they get anything of you.
Don't want to give, don't take.
People like you really piss me off. "They world owes me a job, the world owes me free music, the world owes me free software... But I owe the world nothing, it should pay me for my stuff"
Sigh. If you can't afford the license cost your software must be pretty sucky anyway, as thats barely a couple of months wages.
Rubbish (Score:2)
This is pure nonsense. More OSS use = good, even if only a tiny fraction gives back.
I don't see why some domain specific project should be open sourced - it would mostly benefit the competition of the company, while being completely worthless to the Open Source community at large.
We need lots of friends in proprietary software scene. There are lots of respectable proprietary companies out there.
People like you really piss me off. "They world owes me a job, the world owes
Re:Gah! Kill Qt already! (Score:3, Interesting)
So, what's so abysmal about the GPL? You sound like you think the world would be much better off if Linux, GNU, GCC, Emacs etc. all changed to proprietary licensing (like "WindowsXP from NewEgg") and available for "less than $100 from NewEgg".
Re:Gah! Kill Qt already! (Score:2, Informative)
In the land of $100k for a DB, $70k servers, etc, $2400 is nothing. Now if you want to make the case that $2400 is too steep for a single developer, I've spent that much for Enterprise versions of JBuilder. Maybe it's too much for a shareware developer, or a budget strapped startup, but it's certainly not out
Re:Gah! Kill Qt already! (Score:3, Interesting)
As a matter of fact, there is [sourceforge.net].
Trolltech has no impetus or obligation to port GPL Qt to Win32. But GPL is GPL, so anybody with enough skill can -- and did -- port the codebase to MS Windows. Yeah, it's not perfect (yet), but I've compiled and run stuff written in Qt2.3NC with this GPL'd version of Qt3.x.
--
-JC
coder
http://www.jc-news.com/parse.cgi?coding/main
PS: It's Windows-native and doesn't need X11 to run, in case you're confusing it with the
Re:Author's review (Score:2)
Re:It's the Licensing, Stupid!! (Score:2)
You see, for various reasons I'm stuck on a Win32 development platform right now. I have access to Linux boxes, and I'd love an excuse to get another Mac, but for the time being I'm doing all my grunt work on Windows. So in order to actually do anything useful, I'd have to do at least the initial development under Windows. And that's gonna cost me. Sure, I could download the 30-day evaluation, but that puts a "Buy Me Dammit!" window up on every app, and stops working after 30 days. Not exactly conducive t