Phoronix: Talk Of Qt 4.9, Backporting Qt 5.0 Features
There's a proposal to come up with a Qt 4.9 release, which would back-port more of the Qt 5.0 features to Qt4...
http://www.phoronix.com/vr.php?view=MTE2MDQ
Phoronix: Talk Of Qt 4.9, Backporting Qt 5.0 Features
There's a proposal to come up with a Qt 4.9 release, which would back-port more of the Qt 5.0 features to Qt4...
http://www.phoronix.com/vr.php?view=MTE2MDQ
In general I think that such a move would be sensible, however I could've sworn that a 4.9 release was planned anyway… maybe I'm confusing things…
Prime question: will Qt4 apps be broken by 5.0 release? If so then 5.0 goes to trash can until made backwards-compatible.
That depends on what you mean.
If you asking "will Qt4 apps break if you try to replace your Qt 4.0 installation with Qt 5.0", then of course yes, that is what a major version number change means for both Qt and KDE. You need to keep Qt4 installed for your Qt4 apps.
If you asking "will Qt4 apps break if you try to install Qt 4.0 and Qt 5.0 at the same time", then no, the two should be installable in parallel.
If you are asking "will Qt4 apps break if you try to build them against Qt 5.0", then the answer is "depends". Some things in Qt 5.0 have been changed, removed, or renamed, but the changes compared to Qt3-Qt4 are much smaller, so some software may still be able to work. In most cases, even if they don't work out-of-the-box porting should not be overly difficult, and in fact Qt 5.0 has a porting tool that can automate many of the changes (like the python 2to3 tool).
The major exception is if the software is still using Qt3 support classes, then it will definitely break. But it was announced 7 years ago, when Qt4 came out, that Qt3 support would be dropped when Qt5 came out, and if I recall correctly Qt5 was announced last year, so it shouldn't be any surprise to anyone that qt3 support classes need to go.
One thing I find funny in Qt5 is that apps looks awesome when you run them in Gnome, but look like ass when running in KDE... Ironic, isn't it?
Why is it not possible to make some sort of translation layer for 4.0 apps?
Will this last for long? Or will Qt4 be dropped from distros the next day after 5.0 release?If you asking "will Qt4 apps break if you try to install Qt 4.0 and Qt 5.0 at the same time", then no, the two should be installable in parallel.
Meh. You need to remake software post-release because dependency maker breaks it all. No wonder not many develop using FOSS.If you are asking "will Qt4 apps break if you try to build them against Qt 5.0", then the answer is "depends". Some things in Qt 5.0 have been changed, removed, or renamed, but the changes compared to Qt3-Qt4 are much smaller, so some software may still be able to work. In most cases, even if they don't work out-of-the-box porting should not be overly difficult, and in fact Qt 5.0 has a porting tool that can automate many of the changes (like the python 2to3 tool).
The majority of apps written for Windows XP (since 2001) run under Windows 7 PERFECTLY. Why the hell is it not possible with Qt?The major exception is if the software is still using Qt3 support classes, then it will definitely break. But it was announced 7 years ago, when Qt4 came out, that Qt3 support would be dropped when Qt5 came out, and if I recall correctly Qt5 was announced last year, so it shouldn't be any surprise to anyone that qt3 support classes need to go.
They have, but it is not possible to make it work with no changes at all because of some underlying reorganization of the libraries. This is the case with any such large software project. Programs designed for different versions of .NET are not compatible with each other, either. Although for the most part applications should be able to be designed to work with both Qt 4 and Qt 5.
Of course not. It will be the same as with Qt3: they will stop shipping Qt4 when the software they want to ship stops depending on it.
That is the case with any software. If you want to use the newer versions of windows libraries you also need to recompile. This is hidden from end-users, but developers still need to deal with it.
Because windows ships the old versions of the libraries. It is equivalent to having Qt 4 and Qt 5 installed on the same system (actually it is equivalent to having Qt 1, Qt2, Qt3, Qt4, and Qt5 installed on the same system).
This is possible on Linux too, in fact many people still run Qt 3 apps just fine because they still have qt3 installed. I don't know about other distros, but I know openSUSE makes qt3 available by default. Of course it is only installed if it is actually needed, unlike windows where all of those old versions of the libraries are there bloating your system whether you need them or not.
The win32 API didn't change much. The same is true for X11. The majority of the apps written 15 years that use the X11 API still work.
Also, Qt3 apps don't run in Qt4. The Qt3 compatibility classes are not what you think they are. You still needed to port your app to Qt4, even when using the Qt3 compat classes.