> -----Original Message----- > From: development-bounces+kai.koehne=theqtcompany.com@qt- > project.org [mailto:development- > [email protected]] On Behalf Of > Frederik Gladhorn > Sent: Friday, May 08, 2015 2:40 PM > To: [email protected] > Subject: [Development] Future of Qt Quick 1 in Qt 5 > > Hi, > > I think the dust has settled quite a bit and the declarative module is > becoming better by the day. We have seen it evolve and the new Java Script > engine is running smoothly (and actively worked on, sadly it will have one > known crasher in the 5.5 beta release which has been fixed in the mean > time, so it should be good for everyone with the 5.5 RC).
+1 from me. Porting from Qt Quick 1 to Qt Quick 2 is trivial in the most cases, and the OpenGL dependency can be mostly fixed by software rendering. If we can't agree even for QtQuick1 to be removed in a reasonable time I'm afraid we'll have to stick to all released modules until Qt 6. And I don't want to release a Qt 6 just because we want to remove some libraries from the list of add-ons. One thing to worry about though is Linux distributions: We certainly don't want to let them stick to an old Qt version because there are applications still depending on qtquick1. However, a quick search with e.g. osc for openSUSE shows that this shouldn't be a big problem (somebody please correct me if I did the search wrong): osc whatdependson openSUSE:13.2/libqt5-qtquick1 standard x86_64 libqt5-qtquick1 : libqt5-creator phonon4qt5 plasma-nm5 python-matplotlib python-qt5 python3-matplotlib python3-qt5 stellarium Somebody should probably talk to the stellarium and matplotlib guys whether they need help porting :) Every module we package and test is a source of CI integration problems, and requires build & packaging time, so yeah, removing qtquick1 from the mix would help. Regards Kai _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
