Выпуск фреймворка Qt 5.8

По поводу "не умеете готовить" — я переводил свой домашний проект на Qt c 5.5 на 5.7 где-то в августе — ноябре 2016, проект реально небольшой и в основном переход был с Controls 1 на Controls 2 (заявлено что они должны работать вместе, хотя и не совместимы по API), результаты:

1. Изменили механизм освобождения ресурсов при пуше в stackview, теперь он сам дергает у компонетов createObject. Вот только про то что объект может быть создан еще и из строки с помощью Qt.createQmlObject() они забыли, такие объекты висят в памяти https://bugreports.qt.io/browse/QTBUG-55405
2. список значений в Combobox в диалоге на андроиде показывается под диалогом — косякнули с z https://bugreports.qt.io/browse/QTBUG-55004
3. Дергаешь по старинке var component = Qt.createComponent() + component.createObject() и внутри у тебя FileDialog? Лови краш на второй или третий раз (багу не знаю, отписывался на форуме и в личке мне ответили что поправили), найти смог методом исключения
4. У тебя есть свойство прописанное внутри qml (пусть будет staticValue) и ты задаешь другое свойство с помощью stackView.push(component,{value:"two"}), казалось бы что тут может пойти не так? На практике значение в value попадает раньше чем в staticValue что может быть губительно если там есть вложенные объекты и передается в них нечто через функцию, а не через свойство (что, замечу, у меня было исключительно по причине другого бага Qt — в Combobox из controls 1 нельзя программно выбрать номер итема с пустой строкой https://bugreports.qt.io/browse/QTBUG-51698)

В целом у Qt имхо 2 проблемы:

1. Работа с памятью — имеется ручная работа в C++ и сборщик мусора в JS, но их взаимодействие написано криво — плюсовые объекты (например createQmlObject) не освобождаются сборщиком мусора сами собой, а js наоборот освобождаются. В итоге ты не можешь сохранить где-то js-объект между двумя вызовами формы, его приходится во что-то преобразовывать, а плюсовые объекты наоборот торчат в памяти. Причем работают с памятью правильно не всегда даже в самой библиотеке (см. 1 и, я так подозреваю, 3)
2. Бег впереди паровоза — в результате у них набирается куча багов (опять-таки 1, 2, см. примечание в 4, есть еще проблема с потерей фокуса после диалогов если ее только не поправили, периодически в логах ошибки в стиле "нет поля acccessory" внутри системных компонентов). Думаю, из-за этого же в библиотеке часто попадаются странные технические решения — пункт 4, повесить открытие списка комбобокса на пробел при том что нигде не запрещено его вводить (был такой баг до версии 5.4.1), QMap который на запрос неизвестного ей ключа вставляет его в себя с дефолтным значением, а ты потом долго и упорно пытаешься понять откуда у тебя в базу пришли пустые строки, при работе с файловой системой на винде часть компонентов использует пути вида /C:/my/path (драйвер sqlite, точнее ему этот слеш не вредит), а часть обычные виндовые (QFile), а qml-компоненты могут еще и file:// докинуть.

Причем ситуация с багами самой библиотеки это не особенность именно конкретной версии — мой проект медленно пишется по вечерам еще со времен Necessitas и я постоянно натыкаюсь на кучу мелких проблем, как верно отметили в одном из комментариев на хабре, Qt применительно к QML много лет стабильно сырой. Может, конечно, ситуация стала лучше в 5.8 (я ее еще не смотрел, но обязательно посмотрю), но что-то мне подсказывает что вряд ли.

Толсто. linuxdeployqt был бы очень кстати.
А под мобильные платформы нужно и есть, например androiddeployqt.