C++ GUI Programming with Qt 4 148
Ravi writes "When somebody talks about the Qt Framework, the first thing that comes to mind is KDE one of the most popular Desktops which is built using the Qt library. Qt is a C++ GUI framework created by the Norwegian firm Trolltech which can be used to build applications for a variety of OSes and platforms. The latest version of Qt (Ver 4.0) contains huge improvements over its earlier versions such as advanced modal/view functionality, easy to use template containers and better Unicode support just to name a few. I have been excited about the ease with which one can build GUI applications using Qt. Trolltech provides the library in two licences - the free licence which mandates that the applications developed be released under GPL and a commercial non-free licence which allows one to develop closed source applications using Qt." Read the rest of Ravi's review.
C++ GUI Programming with Qt 4 | |
author | Jasmin Blanchette and Mark Summerfield |
pages | 540 |
publisher | Prentice Hall |
rating | 9 |
reviewer | Ravi |
ISBN | 0-13-187249-4 |
summary | A great book to learn the latest version of Qt (Ver 4.0) to create applications that run natively in Linux/Unix, Windows and Mac OS X |
I found the latest book on Qt titled "C++ GUI Programming with Qt 4" authored by Jasmin Blanchette and Mark Summerfield and brought out by Prentice Hall to be a remarkable book in that it takes the readers through the basics of creating applications using the latest version of Qt and gradually shifts to explain the more advanced concepts of GUI programming using this C++ framework.
The book, all of 540 pages is divided into three parts - the first part containing 5 chapters dealing with Basic Qt, the second part titled Intermediate Qt which contains 11 chapters and the final part titled Advanced Qt containing an additional 5 chapters.
The major work in picking up skills in a new GUI framework revolves around getting to know all the classes and their member functions. And learning Qt is no different. In the first five chapters (Part I of the book), one gets to know the rudimentary concepts behind creating GUI applications using the Qt toolkit. And remarkably, instead of boring the readers with the different Qt classes, the authors take a hands on approach and introduce the concepts via examples.
In chapters 1 through 5, the readers are introduced to rapid dialog design using the Qt Designer, introduction to the main Qt classes such as QApplication, QObject, QWidget and its child classes as well as a good understanding of the concept of Signals and Slots which form the meat behind communication between different objects in Qt. Apart from that the 5th chapter also introduces to the reader the concept of Double buffering - one which is used popularly by the programmers in eliminating flicker in the GUI interface.
The sixth chapter titled "Layout Management" falls in the second part namely "Intermediate Qt". Here one gets to know and tryout the different layout classes that are available in Qt using which one can easily design sophisticated GUI applications. This chapter also gives the reader an introduction to Multiple Document Interface by way of an example.
Event Processing forms the basis of the seventh chapter where the authors explain how to catch events such as key presses and timers. Apart from that the authors also explain the five levels at which events can be processed and filtered in Qt.
Qt has an excellent collection of classes for creating 2D and 3D graphics. And from version 4, the classes are grouped into modules which need only be plugged in on a need to use basis. The primary class which deals with the 2D graphics engine in Qt is the QPainter class. The use of this class has been explained in detail in the eighth chapter titled "2D and 3D Graphics". Other than that, one also gets to know about the OpenGL module in Qt which makes it very easy to integrate OpenGL code into Qt applications as well as the classes which implement printing.
It is really interesting to see that the entire subject of Qt is apportioned into separate chapters with each chapter dealing with a particular topic. For example, if in the 9th chapter, the authors dwell on explaining the classes which implement drag and drop support, the succeeding chapter elaborates on the Model view controller architecture which forms the basis for most item view classes which implement tables, tree views and lists.
Another thing worth noting is that each chapter is explained with a complete stand alone example which makes it easy to try out what one has learned and also get a better idea of the concepts behind the classes that are explained. So while learning say about the container classes in Qt, the reader can actually try out an example and the code is accompanied by step-by-step explanations which makes it much more simpler to grasp the concepts.
All object oriented languages contain what are known as container classes - those which are responsible for creating sorted and unsorted data arrays, vectors and lists. And C++ has a couple of them in the Standard Template Library (STL). Qt has its own wide array of container classes which sport a number of improvements over STL in that they support implicit sharing (Copy on Write) which gives the applications a significant performance boost. In the 11th chapter titled Container Classes, the authors explain the concept of containers and the Qt classes that can be used for the same.
The next two chapters deal with writing and reading data from files as well as databases. And in each case, the concepts are explained with the aid of examples which makes the narration much more interesting to follow.
Qt has good support for Networking as well as XML which is evident from the 14th and 15th chapters which elaborate on the classes responsible for these. Even though these two short chapters do not cover all the networking or XMl concepts, I found them to impart a good idea of the use of a couple of important Qt classes related to networking and XML.
The 17th chapter titled "Internationalization" falls in the Advanced section of the book. I found this chapter to be an eye opener in that, with Qt's robust use of Unicode, it is possible to create applications which support a wide variety of non-english languages.
But one of the very important concept of multi-threading is explained in the next chapter titled what else "Multithreading" where the authors teach how to create threads easily in Qt.
If one looks at any KDE application, it will be evident how the parent application can be extended by use of plugins. A plugin is a dynamic library which implements a particular interface to provide extra functionality to the user. In the 19th chapter, one gets to know how to create dynamic libraries using Qt which can then be plugged into the parent application.
In the penultimate chapter, the authors explain all the platform specific features and tweaks such as using ActiveX in Windows and handling session management in X11. There are also four pages - which I believe to contain the shortest chapter I have ever come across and where a couple of classes which can be used in programming for embedded devices such as mobile phones are listed. By including this tiny chapter, perhaps, the authors were sending a signal to the developer community that Qt is fully ready for use in embedded development.
From start to finish, I found the book immensely enjoyable. The style of narration of the authors which interleaves the example code with the explanation is ideally suited to pick up skills in using any toolkit without getting bored, especially since the bulk of the learning involves acquiring a fine understanding of the classes the toolkit provides. As a bonus the book also provides an appendix which gives an introduction to C++ for programmers who use Java or C#.
The single CD accompanying the book contains Qt library in the source form for the Linux platform as well as for Windows and Mac platforms. I did not have any problems in compiling the source and installing the library in Linux using the instructions provided in the book. And within a little more than an hour (the time taken to compile the source code), I was able to start coding and compiling the examples given in the book. All in all, I find this book to be an invaluable guide in picking up skills in programming in the latest version of Qt (4.0).
Ravi Kumar likes to share his experiences in programming and in using Linux through his blog on Linux."
You can purchase C++ GUI Programming with Qt 4 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I am the very modal of a modern slashdot editor (Score:2, Funny)
Re: (Score:1)
Update on the link (Score:1, Informative)
Re:Update on the link (Score:3, Informative)
It's hard to write a bad review when you know you will make money if people buy it...
Re:Update on the link (Score:2)
Re:Update on the link (Score:1)
Interoperability (Score:2, Insightful)
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)
Does the latter apply to Windows?
Re:Platform license. (Score:5, Informative)
How to get Qt to work with Visual C++ (Score:3, Informative)
Update for 4.2? (Score:2, Informative)
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
Re:Update for 4.2? (Score:1)
Re:Update for 4.2? (Score:2)
If you don't like coding with GTK for Gnome, why didn't you try wxWidgets?
O. Wyss
Re:Update for 4.2? (Score:2)
Neither have I but there's where wxWidgets shines. It might not look perfect on each platform but on any I've seen it looks acceptable. wxWidgets uses native win32 on Windows, Carbon/Cocoa on the Mac and GTK/X11/Lesstif on Linux/Unix. QT might be better but there's no OpenSource outside KDE. IMO there's no reasonable alternative to cross-platform development.
O. Wyss
Re:Update for 4.2? (Score:2)
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)
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.
Re:Update for 4.2? (Score:1)
>> The addition of a Scalable Vector Graphics (SVG) icon engine enables icons to be created from pictures in this vector graphics format.
http://doc.trolltech.com/4.2/qt4-2-intro.html [trolltech.com]
And of course, resizable dialog windows are possible in Qt since the dawn of time. Not only that, they work wonderfully. Trolltech has done quite a good job with its layout managers.
The truth is Qt 4 and specially Qt 4.2 are far, far ahead of GTK, like it or not.
Re:Update for 4.2? (Score:2)
Some Pointers (Score:3, Informative)
Well, I guess then the class QStyle [trolltech.com] is completely useless....and setting a "usertheme" with qt-config is something I must have dreamed then....*g*
Ok...but what is the class QWidgetFactory [trolltech.com] used for then? :-)
mysql-style licensing (Score:1)
> 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)
Re:The free edition (Score:1)
Re:The free edition (Score:1)
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.
Re:The free edition (Score:2)
http://www.trolltech.com/developer/knowledgebase/
or if the distros just fork it
"The distros" could just as easily fork Gtk. Why is this issue specific to Qt?
Re:The free edition (Score:1)
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.
Re:The free edition (Score:1)
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
Re:The free edition (Score:2)
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
Re:The free edition (Score:2)
Well, in this situation there is another option provided by TrollTech:
http://www.trolltech.com/trolltech/products/qt/lic enses/licensing/smallbusiness [trolltech.com]
I dont see much sense in releasing free software and then complain that people are freeloading it.
This "freeloading" I speak of is against the spirit of the GPL, which is designed to encourage community contribution.
Re:The free edition (Score:1)
What are you getting at? gnome is already the biggest drawback of Linux for me, and I never even have it on my machines.
Qt is very nice. (Score:2)
Re:Qt is very nice. (Score:2, Informative)
Re:Qt is very nice. (Score:1)
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
Re:Qt is very nice. (Score:1)
Re:Qt is very nice. (Score:2)
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
Other Book (Score:2)
Fine teaching text, so far.
Design flaws in QT? (Score:4, Insightful)
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)
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?
Re:Design flaws in QT? (Score:3, Insightful)
Re:Design flaws in QT? (Score:2)
Re:Design flaws in QT? (Score:2)
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.
Re:Design flaws in QT? (Score:2)
Re:Design flaws in QT? (Score:2)
Bzzzt. Wrong. Thank you for playing.
Like most dogmatic, arbitrary, rigid, "I have seen the light" rules, this one has poor appli
Re:Design flaws in QT? (Score:2)
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'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
Re:Design flaws in QT? (Score:2)
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
Re: (Score:2)
This is complete bullshit.
In modern C++ Exceptins have nearly zero overhead. And I really can't see why an if (error == code)
Error Codes are EVIL. Exceptions not.
angel'o'sphere
Re:Design flaws in QT? (Score:2)
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
Re:Design flaws in QT? (Score:2)
* they are verbose - I don't want to write by try
* 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
Mod parent up (Score:1)
Re:Actually there is no race condition (Score:2)
Re:Design flaws in QT? (Score:1)
Re:Design flaws in QT? (Score:2)
Re:Design flaws in QT? (Score:1, Informative)
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)
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
Re:Design flaws in QT? (Score:2)
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.
Qt: creating a larger commercial/libre wedge (Score:2)
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
Re:Qt: creating a larger commercial/libre wedge (Score:2)
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.
Re:Qt: creating a larger commercial/libre wedge (Score:2)
Of course with MSDN you're limited to Windows, but on the other hand there's plenty of stuff Qt doesn't abstract fo
Re: (Score:2)
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
Re:Qt: creating a larger commercial/libre wedge (Score:1)
Re:Qt: creating a larger commercial/libre wedge (Score:2)
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.
Your learning experience will not be a killer app (Score:3, Insightful)
gtk? (Score:2)
Re:gtk? (Score:2)
Lots of programs already use Qt (including Google Earth, and Opera).
Re:gtk? (Score:2)
I'm more of a C++ and Python
Re:gtk? (Score:2)
--
Evan
Re:gtk? (Score:2)
Re:gtk? (Score:2)
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
Re:gtk? (Score:2)
Re:gtk? (Score:1)
http://tllts.org/archives/tllts_151-08-02-06.mp3 [tllts.org]
Re:gtk? (Score:2)
Re:gtk? (Score:2)
Qt for non-GUI apps (Score:2)
I for my part am very interested in PyQt or some other approach of wrapping Qt into Pytho
Re:Qt for non-GUI apps (Score:2)
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.
Its too bad its not LGPL (Score:2, Interesting)
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
Re:Its too bad its not LGPL (Score:2)
Re:Its too bad its not LGPL (Score:2)
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... (Score:2)
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.
What do you mean? (Score:2)
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
Re:What do you mean? (Score:2)
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
Re:What do you mean? (Score:2)
Neither. It's pretty easy to spot the worst forms of exception non-safety with a code inspection if you know what you're looking for.
(The reason why I did the code inspection was a failed attempt to integrate a third-party C++ library with KDE.)
Any code which looks like this is immediately suspicious:
QSomething* something = new QSomething();
As is this:
QMySomething::QMySomething()
// ...
{
m_something = new QSomething();
}
QT licensing problems (Score:3, Interesting)
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.
Re:gui and native code - bad combination (Score:3, Informative)
Re:gui and native code - bad combination (Score:2)
Re:gui and native code - bad combination (Score:3, Insightful)
Re:gui and native code - bad combination (Score:5, Informative)
Well, that is exactly what Qt does. Every time you create a widget, you pass a pointer to its parent, and then you can forget about the widget. When the parent dies, it'll kill all of its children, and then they'll kill their children too in cascade. I do tons of Qt programming (that's what we use where I work), and memory management of Qt widgets is a breeze, every widget is hierarchically created, and I just need to kill the window when I don't need it anymore to have it kill all its widgets and sub-widgets. No need for a custom-made wrapper, it's all in there already.
Re:gui and native code - bad combination (Score:1)
Have you ever developed a GUI for a Windows app in C++? They may well have just invented their own C++ standard... it's cr
Re:gui and native code - bad combination (Score:2)
Check out PyQT [riverbankcomputing.co.uk].
Re:gui and native code - bad combination (Score:1)
I've done alot of GUI development going back to System 7 on the Mac, OWL, MFC 1.0, MacApp, ET++, Starview..ect.
QT is by far the best C++ UI (and more) development environment for doing cross-platform development. And, it's a better ActiveX development than ATL or MFC.
M
Re:gui and native code - bad combination (Score:2)
C++ is not C by
Use composition instead of inheritance (Score:2)
You make a very good point. Most programmers do not make the effort to seperate UI elements from their callback infrastructure because they use inheritance to compose functioning widget heirarchies. So they combine program context with their UI. If you use compositio
Re:gui and native code - bad combination (Score:2)
The trouble with drag-and-drop UI designers is that the layout tends to break horribly when the window is resized or the font size changed. (I'm talking about VB, Delphi, and MFC here - there may be other frameworks that have found a way around this problem.) Designers who try to solve the problem by making their forms non-resizable should be taken outside and shot...
Re:gui and native code - bad combination (Score:2)
that's something Qt has solved too, you can define the layout contraints in the designer directly. See it in action with this video: http:/ [trolltech.com]
Re:gui and native code - bad combination (Score:2)
It's obvious you've never used QT4.1.x/C++, or you wouldn't be mentioning malloc(), etc.
If I were to compare coding with the QT4 API to anything it would be Java on steroids. QT uses MOC, a meta-object compiler, to convert gui/api dependent coded to pure C++. Classes
Re:gui and native code - bad combination (Score:1)
You mean, that's why they implemented so many Java-like features in version 4, so they could call it Java on steroids?
Or is it maybe because they took a look at Java and went "hey, there's a lot of cool stuff i there, we can use that as well!"
Re:gui and native code - bad combination (Score:1)
GUIs are a fluid, flexible, dynamic, change-on-the-fly, subject-to-change, feedback-driven kind of feature.
You're absolutely right, despite being a bit redundant. As someone who has used many languages myself, I can tell you that I can implement just that kind of GUI in almost language that I know. But just because you might pick Python over C++ because it's a high-level language doesn't mean that Pytho
Re:gui and native code - Mind Bender. (Score:1)
Re:4.1 is the latest version (Score:2)
Re:subject (Score:2)
Qt is a toolkit, that means a tool for programmers. So it is only natural that is provides a better *programming* experience. If you want better user experience, you have to wait for an end user program. And I am sure that KDE 4 will deliver exactly that.
Re:Qt in an Embedded (Non-Linux) Environment ? (Score:3, Funny)
Re:Replace QT with WX! (Score:2)