Trolltech has announced the availability of the first Qt 4 Technical Preview. Qt 4, the next major release of the popular cross-platform C++ application framework which KDE is based on, is scheduled for final release in late Q1, 2005. Read the online documentation or jump to the download page.
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
Hi
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 ...
Lots of tunning. QString, moc etc. expecting a good bump in startup and speed.
Thanks Ben, looking forward to it ! This, together with a standard objprelink for Linux, plus KDE-libs optimizations, will overall get an even snappier KDE !!!!!!
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.
>Being slightly pedantic:
You are correct in all of this.
That's what I love about Linux. My old piece of crap computer is getting faster all the time.. From kernel 2.4 to 2.6, from KDE 3.1 to 3.2, etc.
In a few years I'll have to downgrade :D
LOL this is exactly my idea about this ;-)
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...
The new kernel is a tad bit snappier on interactive loads, but these improvements has been available for 2.4 as patches for some time. So you may already have them if you are running a distro kernel.
SuSE 8.2 with KDE 3.1 and Linux 2.4.20 felt snappier to me then
SUSE 9.1 with KDE 3.2 and Linux 2.6.4, so I downgraded.
(on a mobile P2 400MHz with 160MB RAM)
Paul.
Well, this is SuSE specific, cause SuSE is a well overloaded Distribution
which (my opinion) is not at all made to achieve the maximum performance!
Slackware doesn't include any of these patches in its default kernels....
To answer the question one layer up: Yes, 2.6 speeds things up. It's a noticable speed increase on all my systems. It may not like your super-old hardware, though, if it is, indeed, super-old.
Rob
I heard that Qt 4 would be broken up so that a command-line program could link to it and not have to drag in all the GUI stuff it won't use. Is that still happening?
yes
maybe this is interesting for you:
http://www.uwyn.com/projects/tinyq/
I think I've something about, qt4 should be compatible to qt3.
Thanks for answers!
Yes, but not without some changes to the build environment and possible also the sources. It's meant be easily portable for developers, not to be completely source compatible.
No, qt4 is not binary compatible with qt3.
no.. quite a few changes are needed... which is why kde 4.0 will be a new release
Well, it is written in the announcement !
"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 :-)
What about QTopia... does anybody know if Qt4 will be good enough to be the base for the next QTopia ?
--
Go Qt go! :D
From what I know it might be based on Qt4 but if you want a Free Software Palmtop Environment look at http://opie.handhelds.org we're surely interested in Qt4.
regards
How much interested are you ?
First, I need the hardware in which I could run a Free Software Palmtop Environment ;)
From reading the texts, it looks really great at the moment.
I'm especially interested in the "interview" model/view framework.
This will sure speed up programs that deal with rather large amounts of data.
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.
Darn it, I don't want screenshots - I want video capture! :)
Of course, I run very multihead, so I don't have 3D acceleration at all. I wonder how it will perform.
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.
Yes ,could some brave soul please post videos somewhere. Now I know there is more eyecandy to explore I can't wait to see it.
please, please, please
has qt always had 'foreach' iterators or is this new in qt4?
I can't wait for qt4
/me drools
It's new in qt4.
They really feel like python looks right ? Cool!
#### Python:
for s in a_list:
sum += len(s)
#### Qt4:
(http://doc.trolltech.com/qq/qq09-qt4.html)
foreach (QString s, list)
sum += s.length();
Errata: I meant so say "python loops". Oh, and the indentation got eaten by the text formatting ;-)
I hope they made use os gcc´s symbol visibility option in version 3.5. Then Kde will fly even more!
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.
Not with gcc-3.x being 2x-3x times slower at building things.
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.)
Have a nice day!
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.
Have a nice Saturday night!
Well, QIODevice::close has no return value. So we are always ignoring what happens at closing time in KDE...
Have a nice day!
wow, that sucks!
Why?
The application is closing down. Who gives a fuck?
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.
Rik