When Qt4 will die?
-
[quote author="mbnoimi" date="1373017903"]
I'm wondering when Qt Project decision makers plan to stop Qt4 forever?[/quote]What do you mean by to "stop Qt4 forever"? Qt 4 will not stop working. "Qt 4.8.5":http://blog.qt.digia.com/blog/2013/07/02/qt-4-8-5-released/ was released couple of days ago. Existing projects can continue using Qt 4 or to be ported to Qt 5.
-
There currently is no set date, but because porting from Qt4 to Qt5 is rather easy, it will rather not be 4 years as was the case with Qt3.
My guess is that patch releases will continue to come out for at least another year.
-
[quote author="qxoz" date="1373205997"]Can you describe problems of Qt 5 which absent on Qt 4. All my project on Qt 4 for now, and i think, is there reason do not port them all to Qt 5. [/quote]
My favorite topic ;))
Here's a quick summary:
http://qt-project.org/forums/viewthread/27510/
http://qt-project.org/forums/viewthread/24857/
http://qt-project.org/forums/viewthread/21785/
And very critical bugs they can't find out how to fix:
https://bugreports.qt-project.org/browse/QTBUG-26013
https://bugreports.qt-project.org/browse/QTBUG-25896For me the most important points are: Drop of QWeakPointer for object tracking, Drop of PostScript support, and still broken QPainter line drawing. Apart from that, for application developers, Qt5 brings no benefits. The benefits are almost purely on the app side.
-
[quote author="qxoz" date="1373205997"]@ Tannin, DerManu
Can you describe problems of Qt 5 which absent on Qt 4. All my project on Qt 4 for now, and i think, is there reason do not port them all to Qt 5. [/quote]For me this bug: https://bugreports.qt-project.org/browse/QTBUG-29331
is a major annoyance but I could work around.Bigger issue: When using a custom stylesheet in my app (for theming) QTreeViews are constantly being re-rendered causing 100% load on one cpu. I didn't have the time to narrow down the problem yet and check if a new bugreport needs to be created but yeah, this is a show-stopper for my app.
Also: The number of dlls you have to bundle is becoming ridiculous and building qt myself also doesn't seem to work because I get compiler errors with my configuration.
=> all annoyance, no gain
-
-
[quote author="Tannin" date="1373284786"]Also: The number of dlls you have to bundle is becoming ridiculous[/quote]Agreed that it's annoying. However, there is a price to pay for a framework that does so many things.
[quote]building qt myself also doesn't seem to work because I get compiler errors with my configuration.[/quote]If you post your configure options and OS info in the forum, someone should be able to help you out.
[quote author="mbnoimi" date="1373328042"]Any way, Qt project has to clarify this matter they've to put a date for killing Qt4 just like Qt3 then we can collaborate to fix Qt5 issues.[/quote]Why? Many people will still want to use Qt 4 for a long time, for two reasons: (1) Existing projects (especially commercial ones) can't always afford to port to a new version, and (2) As you've seen in this thread, Qt 4 works better for some people.
Qt 4 shouldn't be killed yet, since it's still a good product and many people still rely on it.
We don't need to kill Qt 4 to fix Qt 5. For example, Qt 5.1 has many fixes compared to Qt 5.0.2. (The issues listed in this thread haven't been fixed yet, but many others have)
-
bq. Why? Many people will still want to use Qt 4 for a long time, for two reasons: (1) Existing projects (especially commercial ones) can’t always afford to port to a new version
If that projects insist to use old technologies so that's their problem. Qt evolution means killing old versions just like any toolkit in the world (I wonder if there are some people still believe that Qt3 is better than Qt4 or Qt5). By the way, killing old version doesn't mean tomorrow it may takes years but at least this process has to get a date.
-
[quote author="mbnoimi" date="1373332655"][quote]Why? Many people will still want to use Qt 4 for a long time, for two reasons: (1) Existing projects (especially commercial ones) can’t always afford to port to a new version[/quote]If that projects insist to use old technologies so that's their problem.[/quote]Have you ever heard of business risk management, or cost-benefit analysis?
Porting large applications is costly. It takes time to change code, to test the changes, and to fix any issues encountered during the porting process. Even small issues can cost thousands of dollars in software engineering time. That cost should only be borne if there is a clear benefit that outweighs it.
I agree that new projects should use Qt 5 (unless your project would be affected by existing issues, like the ones listed earlier in this thread), but it is unreasonable to expect all old projects to port.
[quote]Qt evolution means killing old versions just like any toolkit in the world (I wonder if there are some people still believe that Qt3 is better than Qt4 or Qt5). By the way, killing old version doesn't mean tomorrow it may takes years but at least this process has to get a date.[/quote]Yes, I agree that old versions will need to be discontinued eventually, and I agree that it will take years. However, I don't understand: Why do you need to know the exact date that Qt 4 is discontinued?
But anyway, to answer your question: There is no date set yet. It will come when Qt 5 is mature.
My previous post responded to your statement :
[quote author="JKSH" date="1373330881"][quote author="mbnoimi" date="1373328042"]Any way, Qt project has to clarify this matter they've to put a date for killing Qt4 just like Qt3 then we can collaborate to fix Qt5 issues.[/quote]...We don't need to kill Qt 4 to fix Qt 5. For example, Qt 5.1 has many fixes compared to Qt 5.0.2. (The issues listed in this thread haven't been fixed yet, but many others have)[/quote]If I understood correctly, you said, "Qt 4 needs a specified end date, in order to fix Qt 5 issues" (please correct me if I'm wrong). And my response was, "No, we don't need a specific end date for Qt 4 -- Qt 5 is already getting lots of fixes without the date". -
A reply for all your post is: I ask for a date for same reason of business risk management, or cost-benefit analysis bla bla bla.
If these companies already knew the date of discontinuing support Qt4 all their business will be safe (ex. Canonical always declares LTS support period & Microsoft does too) and Qt5 bugs may be solved rapidly if they and the community knew the exact date of killing Qt4 (I loved killing term heheheheh) because the deadline will encourage the people to fix any issue they find before migrating process.
By the way, until now I couldn't find migrating process very difficult (by comparing migration from Q3 to Qt4)
-
There is no reason for Qt4 to "die"... There are things I can do with Qt4 that I can't do with Qt5. For example, I can create softwares that I can distribute to old machines like windows xp, etc. (since Qt5 cannot be built with the older compiler MSVC2008). Qt5 support for "static build" is also unstable.
-
bq. Qt evolution means killing old versions just like any toolkit in the world (I wonder if there are some people still believe that Qt3 is better than Qt4 or Qt5).
Dude, as a programmer, I know what you feel, many programmers
like the benefits of new technologies
Stronger expression power, better performance, more tools could be used etc.
But in the real world, shifting from tech A to tech B take cost
they are not free to port, if any better technologies will replace
old technologies, I believe that(my own opinion) many mfc projects
will be killed instantly, many programmers don't like mfc but they have
to maintain the codes.I always hoped that the industries could adopt new techs faster, but many
industries are very conservative.bq. For example, I can create softwares that I can distribute to old machines like windows xp
Don't know what are you talking about, what stop you porting Qt5 apps
onto winXP?vc2010 and mingw could compile Qt5 codes. -
I am not switching to Qt5 because I am afraid of more bugs than in Qt4.
So I am also happy with the release of Qt4.8.5I also think, that the devs concentrate more in QML than in C++ or have to do both. With that, new bugs and errors comes. I have to create a professional desktop software and I also reporting bugs, but most of them will be graduated to "Nice to have" or get a low prio for fixing.
Let me give some examples:
- In Linux, local storage html can load other files with relative links. In Windows, that doesn't work (reported: https://bugreports.qt-project.org/browse/QTBUG-32303 )
- Deleting QGraphichsObject can be deleted, but don't have to be. I don't know, why (see: http://qt-project.org/forums/viewthread/29534/#131808 ). I don't know, how to explain in the Bug Tracker
- The class QTextDocumentWriter is not really useful for odt support (get a low prio: https://bugreports.qt-project.org/browse/QTBUG-29555 )
- translate() in QGraphicsView doesn't work. I add a note for a work around ( http://qt-project.org/doc/qt-4.8/qgraphicsview.html )
At the moment, I can live without any new features. But my start with Qt5 will be with QML and C++ together for mobile development.
-
bq. I am not switching to Qt5 because I am afraid of more bugs than in Qt4.
So I am also happy with the release of Qt4.8.5Let us hope that after Qt5.2 release, digia would focus on bugs fix.
The market of desktops keep shrinking, good support of mobiles
become important in these years.I don't feel surprise if they place
the full android and ios support before bugs fix. -
The desktop market is not shrinking, it is more becoming fusioned with the mobile market. Now, you have to develop more mobile software, which works with your desktop application together.
Let me give a simple example: You create a simple presentation and now, you want to show it. Creating this presentation on a PC is more comfortable than on a mobile device, but showing your presentation would be easier with a mobile device. It is not more up to date, to take your notebook with you and plug it in for that. Better would be your smartphone for that.
So both is important. But it is always depending on your field of work :)
