OSNews

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/

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.

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

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

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

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.