“Nowadays, it is difficult to imagine many applications being able to function without relational databases to back them up. For this reason Qt provides a range of classes in the QtSql module [.pdf] that work with various relational database management systems. Relational tables and queries can also be used as the basis of Interview models.”
I really expected a tangled mess of macros and obtuse “C++isms” [copyright fretinator], but I was pleasantly surprised. They have exposed the Database world in a very elegant and simple way. I believe this framework lends itself to easy-to-read, manageable data access code. Kudos!
I’m really suprised that you expected that. If Trolltech for one thing is none it’s their clean API.
I usually refer to them as the ‘API fetishist’s’:-)
I was just comparing it to other C++ frameworks I have dealt with in the work world. I am not very familiar with QT, but based on this example, I am definitely going to look at QT further. I like very clean, OO frameworks.
It’s very nice indeed but it’s still C++. After using C#, Java, Python and friends it feels so ugly, old and overly complex. However if I had to use C++, I would probably use Qt.
It’s very nice indeed but it’s still C++. After using C#, Java, Python and friends it feels so ugly, old and overly complex.
For a lot of my projects, the performance/overhead of those languages are still enough of a hindrance that I have to stick with C++, but luckily, there are very mature Python bindings for Qt at http://www.riverbankcomputing.co.uk/pyqt/ and Trolltech has official Java bindings for Qt http://trolltech.com/products/qt/jambi
There are even bindings for C#, although I don’t know if they’re as good as the others http://cougarpc.net/qyoto/
Or if you prefer Ruby: http://rubyforge.org/projects/korundum/
Or if you prefer Ruby: http://rubyforge.org/projects/korundum/
Yes, you can use the Qt::Sql* classes with QtRuby. But Rails ActiveRecord works great with QtRuby and is a lot more rubyish. The latest QtRuby 1.4.9 release has a couple of Rails support classes to make it easy to use ActiveRecord or ActiveResource with the Qt model classes such as Qt::AbstractItemModel or Qt::AbstractTableModel.
one word: QtJambi.
(one could also go on about the excellent python and ruby bindings too. the C# ones (kyoto) are coming along nicely as well)
Qt is by far the best framework in any language that I’ve ever seen. Not just C++, it’s also better than the Java class library or the .NET components. Qt makes C++ a pleasure to use.
The biggest problem that I have with Qt is that I tend to underestimate it. Sometimes I start implementing some feature before I realize that there is already a class/function for that in Qt. They just do an awesome job of making all the common tasks absolutely trivial, and the less common tasks easily possible.
Going from Qt to working with the Mozilla framework was/is a nightmare. From a clean, intuitive API to a mess of obfuscation, macros, and generated code, invented types, obscure connections, counterintuitive API design, and worthless documentation. I love programming, but Mozilla was almost enough to beat that out of me. As soon as I can I’m going back to Qt.
I have to agree with you, QT is an excellent framework. However, I wouldn’t recommend using it for Java. By doing so, you sort of get the disadvantages of both systems. Your code will be platform dependent, and it will still load slower than a well written C++ app.
Besides, java allready have a GUI API that is equally good as QT. There is nothing you can do in QT that you can’t do in swing. The only reason for using QT for java would be if you know QT, but not java swing.
I have to agree with you, QT is an excellent framework. However, I wouldn’t recommend using it for Java. By doing so, you sort of get the disadvantages of both systems. Your code will be platform dependent, and it will still load slower than a well written C++ app.
Qt is a cross-platform framework, so the code will not be platform dependant.
Besides, java allready have a GUI API that is equally good as QT. There is nothing you can do in QT that you can’t do in swing. The only reason for using QT for java would be if you know QT, but not java swing.
Last time I looked, the Swing native look-and-feel was quite bad compared to Qt. Also, you couldn’t easily do things like dynamically add/remove items from menus in Swing. The Java listener event model is also much more cumbersome than signals and slots.
Has Swing changed so much since I last looked?
Edited 2007-07-18 23:06 UTC
I have to agree with you, QT is an excellent framework. However, I wouldn’t recommend using it for Java. By doing so, you sort of get the disadvantages of both systems. Your code will be platform dependent, and it will still load slower than a well written C++ app.
Well not quite. Your code will still be cross platform, since both Qt and Java are cross platform. Of course you will be relying on some native libraries, so you will have to distribute different Qt libs for each platform you intend to support. The code however will be the same.
Also, while you do have the overhead of Java, if you heavily use Qt functions, it should be faster than using the Java class library, because all the heavy lifting is done in native code. You also get better integration into the platform than you can get with Swing.
Besides, java allready have a GUI API that is equally good as QT. There is nothing you can do in QT that you can’t do in swing.
Of course, there is also nothing that you can do in Qt that you can’t do in pure C, but it will be a lot more work without Qt. Swing is ok, but the API design still isn’t as straightforward to use as Qt (at least in my experience). Then there is the system integration issue, as well as performance. Keep in mind that Qt is not just a GUI toolkit (as this article demonstrates), and if you’re using it for database access or any of the hundreds of things it does, you might as well use it for the GUI as well. It will certainly look more native than a Swing UI.
Edited 2007-07-18 23:03
You will definetly not regred going QT, There are no single word to express the quality of qt, but if one were to make up a bastardized work, it would definetly be a mixup of Brilliant, Masterpiece, Excellent, and such
<quote>Nowadays, it is difficult to imagine many applications being able to function without relational databases to back them up</quote>
I really wonder how true this assertion is.
All relational databases except sqlite have a ton of admin overhead. And sqlite is in many cases overkill.
Well, after 9+ years as a programmer (several companies), I have worked on probably 100+ applications. I can’t think of one that didn’t connect to a database (btw, they were all relational).
Obviously, there are some out there that do not require a full-blown database, but once an application grows to a certain size, reading/writing data to text or random files becomes more of a hassle than it’s worth.
A more generic term would be a datastore. This includes CSV files, XML, etc. Most API’s allow you to access these kinds of files in the same manner as accessing a full-blown database.
If you are a CS or CIS student, pack yourself with some good database theory. You’ll need it!
[EDIT: Cleaned up quoting, clarified what kind of student]
Edited 2007-07-18 21:37
Data store is substantially more general than relational sql.
I’m not saying sql isn’t useful, it’s just only useful for a very small slice of the whole problem domain. In many cases I’ve seen or been involved in I’d say databases were vastly over applied.
One of the last projects I worked on was a custom WMS/WFS implementation. It was heavily, heavily relational. One of the things I did was to move about 90% of the data out from a relational system over to editable or utility generated flat files.
I could do this because all the data of interest (mostly image store) was on the file system anyways. And to boot I got a substantial performance boost out of it.
I ended up identifying the transactional and non regeneratable data which stayed in a database
I was going to develop a new cross-platform application for personal needs and I was pondering whether I should develop a web application (as usual) or give a try to Qt (since web standards are making me mad). It happens that database connectivity was one of my main preoccupations…
While the sample chapter is a bit shallow on details, it’s a great introduction to the module. Guess my mind is settled and I’ll just have to give a try to Qt.
Still, I am concerned on portability. If I develop an application by sticking to standard libraries and the Qt framework, could it be possible to port the code without doing anything else than a recompile? While I use Linux, a port for MS-Windows would still be needed.
> If I develop an application by sticking to standard
> libraries and the Qt framework, could it be
> possible to port the code without doing anything
> else than a recompile?
that’s the idea. just stay away from system specific calls or relying on platform oddities. if you stick mostly within the standard c++ and Qt API you’ll be fine.
kde4 is over 5 million lines of code including koffice and ported applications in extragear and with a few exceptions (such as kwin which is naturally pretty well tied to x) it’s compiling on linux, solaris, *bsd, windows and macos.
and we have the burden of our own libraries to maintain which tend to want to do a lot of “lower level” things that most apps don’t need to pay attention to.
with each passing release of Qt more and more needs are taken care of as well. QSsl is a good recent example of that.
Thanks for the info, that is definitely a relief. C++ isn’t renowned for cross-platform standard compliance, so let’s hope I won’t run in too many problems when it’ll be time to compile for MS-Windows. I suppose it won’t be too bad as long as I stick with GCC…
My suggestion: Try to isolate your code logic as much as possible from the GUI code. Use some simple mechanism like broker classes if you can.
If anything, write your algorithmns and unit tests to the point that they’re as independent of Qt as possible. Think in terms of being able to possibly change out the GUI portion if necessary.
While the sample chapter is a bit shallow on details, it’s a great introduction to the module. Guess my mind is settled and I’ll just have to give a try to Qt.
More details in the excellent documentation:
http://doc.trolltech.com/4.3/index.html
The Qt Assistant gives you access to the docs in an easily browseable/searchable manner.
Still, I am concerned on portability. If I develop an application by sticking to standard libraries and the Qt framework, could it be possible to port the code without doing anything else than a recompile?
Yup. I’ve done that many times. Just make sure to stay away from platformisms like specific path separators or file locations. Aside from that you shouldn’t have any problems.
Having used various toolkits and SDKs, Qt is the best toolkit there is.
The C++ committee should endorse it and make it the official C++ API.
Qt shows the real strength of the C++ language.
Umm…you can’t be serious???
Have you tried to use this on a major commercial project?
Tried to port an app from qt2 to qt3 to qt4 ?
Hehe…Qt is currently probably slightly above many of the toolkits out there, but it’s no where anything close to ideal or perfect. It’s vastly bloated, it’s vastly non orthogonal, with qt4 it tries to borg you, and with qt4 they introduced some severe performance issues if you’re trying to do something like CAD type things.
If you’ve tracked their mailing list you may have noticed that the demographics of their users have changed over the past couple of years. I think if anything they’ve been losing customers with qt4 especially.
Edited 2007-07-19 15:34 UTC
Have you tried to use this on a major commercial project?
No, haven’t had the chance yet. I do use it at work for projects though, and I have a couple at the 10,000 loc mark. I actually rewrote a small app (~5000loc) from MFC to Qt and achieved the same functionality with just over half the code.
It’s vastly bloated
I would rather have the toolkit contain code to do something so I don’t have to reinvent the wheel. That’s not bloated, that’s saving me a ton of time.
it’s vastly non orthogonal
Example please? I haven’t experienced any unwanted side effects in my code.
with qt4 it tries to borg you
That doesn’t even make sense. It doesn’t force anything on you.
with qt4 they introduced some severe performance issues if you’re trying to do something like CAD type things.
What exactly is slower? I know there were some performance problems in Qt 4.0, but have you tried the latest 4.3? I haven’t hit any problems with performance, and I am actually working on a “CAD type” (well actually more like “Visio type”) application now.
Have you tried to use this on a major commercial project?
Tried to port an app from qt2 to qt3 to qt4 ?
I’ve implemented at least 4 major projects using Qt3. I ported one of them to Qt 4 and it was… a little slow and painful but I was under no illusion that it wouldn’t be. Trolltech made it quite clear that they were massively revamping the API. I made an informed choice.
Hehe…Qt is currently probably slightly above many of the toolkits out there, but it’s no where anything close to ideal or perfect. It’s vastly bloated, it’s vastly non orthogonal, with qt4 it tries to borg you, and with qt4 they introduced some severe performance issues if you’re trying to do something like CAD type things.
It is not “perfect” (nothing is), but I think your detractions are flawed because:
It is not vastly bloated – since Qt4, all functionality has been separated into separate libraries, i.e. QtCore, QtGui, QtSql, QtNetwork, QtXml, etc. etc.
I’m not sure what you mean by orthoganal, but it’s a cross-plaform toolkit – it is supposed to provide modules for different features of an OS. These features (as I have previously mentioned) are all well-separated into libraries.
It tries to “borg” you. What does that actually mean?
I know there are some real, valid shortcomings in Qt, but I see none of them here.
Edited 2007-07-19 17:15 UTC
The trolls are involved with the process of defining the new C++ standard, so I guess quite some of their work might end up in there.