[Development] Future of Qt Quick 1 in Qt 5

[Koehne Kai]

> -----Original Message-----
> From: development-bounces+kai.koehne=theqtcompany.com at qt-
> project.org [mailto:development-
> bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of
> Frederik Gladhorn
> Sent: Friday, May 08, 2015 2:40 PM
> To: development at qt-project.org
> 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