Five new technologies, codenamed Arthur, Scribe, Interview, Tulip, and Mainwindow are being incorporated into the next major version of Qt 4.0. The technologies are:

Arthur: The new painting framework

Scribe: The Unicode text renderer with a public API for performing low-level text layout

Interview: A model/view architecture for item views

Tulip: A new set of template container classes

Mainwindow: A modern action-based mainwindow/toolbar/menu and docking architecture

This is a preview of some of the Qt 4 libraries, not of the entire application development framework. Most notably, new versions of Qt Designer and Qt Linguist are not included. The Technology Preview is meant to be tested on a limited set of platforms only.

Qt 4 still is in a very active state of development. Not everything is ready for prime time, and there are significant omissions. Most importantly, this Technology Preview is not meant to be used in production code or even for application development. Not all backwards compatibility functionality is in place yet but you're able to write small programs.

Comments

Does anyone know how is Qt4 going to do in terms of speed ? I think I read some time ago that one of the focuses for Qt4 was to speed up the libraries, besides adding functionality, but I don't see any reference to this in the Public Release info ...

Being slightly pedantic: objprelink has nothing to do with Linux, it addresses an issue with gcc's C++ implementation. Any system that uses gcc will be subject to the same problem. If you use a different C++ complier for Linux (does anybody?), you don't have the problem. And yes, gcc has addressed the problem directly, so it's an issue that will fade away.

An old P350 with 128mgs of Ram feels snappier with KDE3.3 than with KDE 3.1.
Does the upgrade from 2.4 Kernel to 2.6 improves performance, too? If so, I'll certainly upgrade the kernel on this slackware box...

"Compatibility with Qt 3: In order to minimize the work to migrate to Qt 4, Trolltech will provide comprehensive porting documents, tools and libraries. Most importantly, Qt 4 will provide an extension library that applications based on Qt 3 can link against to use obsolete classes. Using a separate library allows us to provide more compatibility than ever before, without bloating the Qt library with redundant functionality. This also means that developers can gradually begin to take advantage of Qt 4 features while continuing to use familiar Qt 3 functionality. "

I think this is optimal. Everyonce in a while backwards compatibility needs to be broken to implement fundamental changes. But the choice of a compat library is a great decision they made.

In the end, I think that both Qt and KDE should aim at keeping a very slow pace for jumping into "incompatible" versions, so that they can give a stable dev target to developers ... and I think they are doing a great job at it. I just hope the next jump in KDE (4.*) is designed with a life/cycle of a few years. At least two or three. KDE is already a mature platform :-)

The example apps have been stripped out of the preview (for size i presume), but in its place are several demos and boy are they eye candy. swirling alphablended boxes that are stretching and moving in 3d. :) yum. worth compiling just to play around with the arthur demo.

I was wondering, too -- as well as being a little afraid that a lot of the work we're currently doing for Krita would be obsolete, but that worry proves to be unnecessary -- and I noticed that performance of the alphablended primitives was a bit sluggish with plain X11/XRender (nvidia card, nv driver), and that it was quite smooth with the nvidia driver and presumably OpenGL, but that it meant X took 100% CPU.

Does anyone know if Trolltech is considering providing C++ exception support within Qt soon? I know I've read that it's been a vague/opinionated problem in the past (bloat/lack of compiler support), but it's not much of an issue today. Some people may disagree with exception-based error-handling but I personally love the concept, and have been spoiled coming from the Python world. It's one of the few downsides I see against using it for C++ development.

As far I know, it would break compatibility with gcc < 2.95. I'm not sure if Qt or KDE wishes to do this, and would imagine it's one of the major reasons they're not sported, rather than a programming dislike. Do correct me if I'm wrong.

One of the gcc 2.95 holdouts had been FreeBSD and my understanding is that they are looking at making the move to gcc 3x in the next few months. I'm not sure but I think that it's possible stable Debian may be another holdout, but given even the longest life expectancies of a platform it seems reasonable to expect that by next year when KDE 4 is coming out the gcc 2.95 issue could be history.

FreeBSD already shifted to gcc 3.x quite some time ago. Currently I am using gcc 3.3.3. Not the cutting edge, but a darned sight newer than 2.95. The move has already been made and there's nothing left to do except declare the 5.x branch stable...

The problem with using exceptions in a library is that it forces the user to also use exceptions. If the user does not, than every minor extraneous error is going to crash their application. For example, access a file without the necessary permissions, and the program rudely crashes. In addition there is the tar-pit problem to worry about. While the geniuses at Trolltech are certainly capable of navigating the exception tar-pits, most users are not. See for more information.

Hm, but isn't the word "crash" wrong for this situation. I mean, if an exception is not caught, the program terminates in a controlled manner.

Also, the forcing argument has some problems. The first is, it goes either way: If Qt uses exceptions, users are forced to use them. If Qt does not use them, users are forced to use another error reporting scheme. Currently it is not even unproblematic to use exception in you own code if you use Qt, because some users could have compiled Qt without exception support. This will lead to crashes. So Trolltech should at least make a clear statement that Qt 4 should be compiled with exception support.
The second problem with the argument is, that properly used, exceptions do not really force users so much. For example, with the file permissions you described, there return code as error reporting would probably still be used. If exceptions were only used for truly "exceptional" circumstances, users would probably be content with not handling exceptions, and just terminating the program. Of course this depends quite a bit how thouroughly exceptions would really be used.

1) While "crash" was the incorrect word, I doubt users will much care about the distinction.

2) The "forcing" is a problem. I cannot choose to ignore an exception. I must handle it or my application terminates. But I can ignore an error, even safely in some circumstances.

3) If exceptions were only used for "exceptional" situations, it wouldn't be too bad. But what guarantee will there be of that? This is an area of policy, and without seeing that policy and the mechanisms to enforce it, I simply can't trust it. What's to stop some C++ "purist" at Trolltech from propogating a close() error as an exception?

4) I agree that Qt should be compiled with exception support, even it if doesn't use exceptions itself.

I do not have a problem with using exceptions. I do have a problem with using them in a library, and a lower level library at that, however.

I think not having exceptions in Qt is the major weakness of Qt. All other methods of error handling just lead to massive code bloat.

I assume you mean some sort of Device::close() in your example. You should not ignore an error on close() if that handles a file descriptor for instance, because then there is something seriously wrong with your program.

"Forcing" is not the problem, its us programmers to forget to handle possible errors. Too many people are just too lazy, postpose error handling and forget about it after a while.

And yes, 'crash' is the wrong word, because if there was a QBaseError or something you could just catch that in main() and the program would always terminate with at least an error message, if you forgot to catch the exception at the proper place. Big difference.

The trouble with forcing exceptions to be managed is simply that the majority of programmers don't have time to manage every error, or know every error that might be thrown in a given situation. The classic problem, or course, is whether to continue with potentially bad data/state, or to fail. Exceptions ensure the latter in most cases.

Personally, I prefer being able to explicitly handle errors myself knowing what might potentially happen and how critically it will affect my data and running integrity.

The danger of requiring expressions is best expressed by reference to many, many, many pieces of Java code that are running around with:

try
{

}
catch (Exception e)
{

}

It turns up much the same arguments as strong vs. loosely/dynamically typed languages.

I have seen a bit of C++ code, and I have never seen that style, i.e. writing catch-blocks but not doing anything in them. I suspect that almost no C++ programmer would come up with this idea. I have not seen much Java code, but I think there is the difference of checked exceptions, which do not exist in C++ in the way of Java. Such checked exceptions could lead to that style of coding. So, what I am trying to say is basically, this misuse of exceptions will not be seen in C++.
Also, you will not loose any control of handling errors if exceptions are used. Of course, if you really want to deal with *all* exceptions yourself, surround you code with a catch-all handler. A different question is, if that makes sense (Usually not).
I also think that your argument that many programmers do not have the time to manage every error is a very good one in favour of exceptions, since the default behaviour of terminating if nothing is done is the right thing to do then.

I am sorry but terminating is not a good solution: the unsaved document... lost! So for me, it is little different than a crash, so perhaps it is not an abrupt crash but a more controlled one.

(Perhaps you will tell me that you can make an emergency save while for a real crash you cannot. But the end-user will not care, for him it is and remains a crash, as the program has terminated abnormaly.)

Yeah, it is not entirely unproblematic. But I really think ignoring errors is worse. Think of an abnormal situation which prevents an application from being able to save a document. Suppose this condition is detected while opening the file which is being worked on. Suppose that is ignored. The user will be happy with editing his important document, and only after he has made his changes, working for some time, out of a sudden, his data will be lost because he can not save. If the application would have terminated right at the start, I think that would have been the better alternative.

The filesystem may not have finished writing the data when close() returns. If it hasn't, you can find out by checking the return value of close(). Many apps really should check the return value of close(), especially when there's a even the slightest chance the file is on an NFS partition.