Qt Widgets vs. Qt Quick - Qt

Добрый день,
нужно написать десктопную программу с поддержкой различных платформ. Остановились на Qt.
Вот тут пишут, что для таких целей лучше использовать Widgets, хотя можно и использовать Qt Quick 2.
Глядя какими темпами идёт развитие Qt Quick 2, возникает вопрос, а может стоить всё таки посмотреть в эту сторону?
Хочется поставить на правильную лошадь и через пять лет не оказаться у разбитого корыта.

Спасибо.

Здравствуйте, Iso12, Вы писали:

I>Добрый день,
I>нужно написать десктопную программу с поддержкой различных платформ. Остановились на Qt.
I>...
I>Спасибо.

А можно подробнее про то, что должен уметь GUI программы? Если нет требований к супер high dpi, сложным плавным анимациям, сильно кастомизированным интерфейсам и т.п., то берите widgets. Зрелая и стабильная технология, хорошая документация, примеры и обучалки (чего не скажешь про QtQuick). Технически намного проще отлаживать. Примеры прог на виджетах: ICQ, Telegram.

QtQuick сейчас очень активно развивается. Пока под десктопы нет внятной поддержки всяких док окон и некоторой другой десктопной мишуры. Опять же — написание кода требует чуть больших навыков. Нужно уметь без фанатизма разделять GUI и логику, становится более сложной отладка QML. Чистых GUI на QtQuick я с ходу не припомню. Могу сказать, что Blizzard launcher юзает смесь виджетов и QML.

Здравствуйте, SaZ, Вы писали:

SaZ>А можно подробнее про то, что должен уметь GUI программы?
Программа должна уметь:

Здравствуйте, SaZ, Вы писали:

SaZ> Если нет требований к супер high dpi

У виджетов проблемы с этим?

Здравствуйте, Amygdala, Вы писали:

SaZ>> Если нет требований к супер high dpi
A>У виджетов проблемы с этим?

Ну это не совсем проблема виджетов. Это проблема практически любого GUI на многих десктопах (всякие UWP не в счёт). Просто виджеты практически всегда риcуются и анимируются на CPU (за исключением некоторых прямых вызовов типа DrawFrameControl, но тут я не уверен). Соответвенно всякие сложные сцены даже при FullHD уже начинают подкушивать процессорное время. Один раз пришлось отказаться от QGraphicsScene в пользу QQuickWidget и реализацией этой конкретной сцены на QML.

QtQuick же рисуется с большего на GPU и в отдельном потоке. И всё это из коробки.

Здравствуйте, Iso12, Вы писали:

I>Здравствуйте, SaZ, Вы писали:

SaZ>>А можно подробнее про то, что должен уметь GUI программы?
I>Программа должна уметь:
I>

I>считывать ( и писать) информацию из файлов,

I>передавать и получать данные через TCP/IP сокет,

I>отображать информацию для редактирования,

I>рисовать блок диаграммы ,

I>посылать данные на печать,

I>создавать pdf файлы.

Моего ответа достаточно (включая комменты в этой ветке)? Если диаграммы не сложные — берите виджеты. А если заранее сделаете нормальную архитектуру и отделите логику приложения от GUI, то не будет никаких проблем с миграцией на другие технологии.

Здравствуйте, Iso12, Вы писали:

SaZ>>А можно подробнее про то, что должен уметь GUI программы?
I>Программа должна уметь:

I>считывать ( и писать) информацию из файлов,
Не GUI
I>передавать и получать данные через TCP/IP сокет,
Не GUI
I>отображать информацию для редактирования,
Обычный TextEdit, или надо что то такое Это пример на QWidgets
I>рисовать блок диаграммы ,
А вот тут можно выбрать, делать самому или QML qtcharts или QWidgtes qwt
I>посылать данные на печать,
QPrinter
I>создавать pdf файлы.
Смотря какие, может будет достаточно QPrinter или придется тащить NCReport

К тому что написал SaZ добавлю:
У qml есть плюс, интерфейс пишется быстрее.

Здравствуйте, Igore, Вы писали:

I>У qml есть плюс, интерфейс пишется быстрее.

Тоже в плюсы QML добавлю, что различные компоновки и привязки делаются элементарно и очень быстро. Анимации в пару строк итд.

Однако, одна из главных проблем QML в том, что тут работает, там не работает, а здесь рыбу заворачивали. Сыроватое оно.

Здравствуйте, Iso12, Вы писали:

SaZ>>А можно подробнее про то, что должен уметь GUI программы?
I>Программа должна уметь:
I>