Я новичок в Qt и не совсем понимаю разницу между Qt Quick Project и Qt Widget Project.
Я надеюсь создать программу, которая рисует решетку из шестиугольников, которую пользователь может вращать и сдвигать, а также панорамировать, увеличивать и уменьшать масштаб. В конечном итоге это будет MIDI-контроллер. Какой тип проекта лучше всего подходит для этого и почему?
Я надеюсь, что это сработает как на настольных, так и на мобильных платформах.
Ответы:
Примечание: виджеты Qt были заменены виджетами QML; этот ответ отвечает на заданный вопрос, который теперь является строго историческим вопросом о старых виджетах Qt.
Qt Quick - это декларативный пользовательский интерфейс в стиле смартфона с поддержкой множества интересных переходов анимации, которые распространены в приложениях для смартфонов. Quick также является хорошим выбором для быстрой разработки прототипа. Qt Widget - это традиционная модель пользовательского интерфейса, ориентированная на рабочий стол.
Прямо сейчас (до Qt5) поддержка Qt Quick для функций настольной системы отсутствует (но улучшается). В Quick не так много поддержки меню, панелей инструментов, диалогов и других стандартных действий рабочего стола, тогда как Widget поддерживает эти элементы очень хорошо.
Вы хотите, чтобы ваше приложение выглядело и чувствовалось естественным на платформах настольных компьютеров и планшетов, или вы создаете простое приложение на основе собственного виджета пользовательского интерфейса? Как сказал Мэт, если Qt Quick поддерживает нужные вам функции, это, вероятно, будет вашим самым быстрым подходом. Если вы хотите создавать полнофункциональные настольные версии, Qt Widget, вероятно, будет вашим лучшим выбором.
Как человек, профессионально разрабатывающий приложения qt, я в любой день выберу qml вместо виджетов.
Виджеты хороши для самых простых вещей, но, как только вам понадобится создать что-то более интересное, виджеты очень скоро выйдут из строя.
Qml просто более гибкий, вы можете привязать элементы где угодно, вместо того, чтобы использовать ограниченную систему компоновки виджетов. Недостатков зависимости от платформы почти нет, хотя виджеты полны ими. А система привязки свойств упрощает синхронизацию пользовательского интерфейса с моделью.
Примечание : В этом ответе «виджеты Qt» относятся к приложению виджетов Qt, которое можно выбрать при создании нового приложения Qt.
Это спустя семь лет после того, как вопрос был впервые опубликован ... но вот моя « цель » - два цента, чтобы нейтрализовать любые события, произошедшие с тех пор.
В проектах Qt Quick используются QML и JavaScript .
В проектах Qt Widgets используется код C ++. (PyQt и PySide, привязки Python для Qt, использует Python.)
Таким образом, виджеты Qt можно считать низкоуровневыми по сравнению с Qt Quick. Но это означает, что в конечном итоге проект Qt Widgets будет работать быстрее и иметь лучшую производительность. Однако быть на низком уровне может быть хорошо, поскольку виджеты Qt более доступны для собственного API ( модуль QtCore , таблицы стилей Qt и т. Д.). Тем не менее, он часто используется для разработки настольных компьютеров.
Qt Quick больше ориентирован на разработку мобильных приложений (хотя его все еще можно использовать для разработки настольных компьютеров). Он имеет готовые к использованию всплывающие окна , анимацию , вкладки и макеты, всплывающие элементы , ящики и обычные элементы управления; все повсеместно используются в мобильной разработке.
У обоих есть uiфайлы, которые работают с QtDesigner, обеспечивая высокоуровневое представление для настройки макетов и создания интерфейсов. (В Qt Quick это расширения .ui.qml. В виджетах Qt они есть .ui.) .uiФайлы не являются ни обязательными, ни необходимыми: у вас есть выбор делать дизайн и макеты программно с использованием QML / JS или C ++ / Python.
Если вы совершенно новым для программирования, я предлагаю иметь взгляд на Qt Quick первый. Лично я считаю, что Qt Quick требует более мягкого обучения и с ним легче работать для выполнения множества проектов. Не зря он называется «Qt Quick ». (Не смотрите свысока на Qt Widgets, у них есть несколько хороших модулей, которые превосходят QtQuick.)
Однако, если вы были программирование с помощью C ++ или Python раньше, я бы предложил взглянуть на Qt Widgets первым, чтобы привыкнуть к их механизма сигналов и слотов и модулей , которые могут заинтересовать вас (например sql, network, gui) наряду с программированием конструкций (например , программирование модели / представления для отображения данных).
Особенно с C ++, большинство библиотек, отличных от Qt, которые используют while-loops для обработки событий, это не относится к Qt. Они используют сигналы и слоты .
В конце концов, даже если вы в основном используете виджеты Qt, вы можете захотеть взглянуть на Qt Quick, поскольку он предлагает декларативный язык высокого уровня для работы и позволяет вам быстрее настраивать вещи. (Специально для мобильной разработки.)
Qt предоставляет множество примеров для проектов Qt Quick и Qt Widget , а также форум . Вам не стоит беспокоиться о помощи в долгосрочной перспективе. (Не забывайте StackOverflow!)
До сих пор мы относились к ним как к отдельным объектам. Но можно интегрировать QML в C ++ . Это позволяет вам использовать Qt Widget, C ++ и другие модули. Например, QtQuick предоставляет, TreeViewно не предоставляет TreeModel, который может / должен быть зарегистрирован в QML из C ++. Часто существует разделение задач , когда Qt рекомендует разделять программы на пользовательский интерфейс и логику на QML и C ++ соответственно.
Это также пригодится, если, скажем, вам понадобится серверная часть для интенсивных запросов SQL, алгоритмов или асинхронных запросов http / xml. Разве это не круто? Интерфейс QML / JS плюс бэкэнд C ++. Полный стек Qt'er. :-)
(То, что я не пробовал, - это бэкэнд Python. Я еще не касался PyQt ...)
Qt Quick по умолчанию использует декларативный диалект QML, JSON с включенным встроенным ECMAscript. С помощью виджетов Qt дизайнер может создавать таблицы стилей, а разработчик выполняет собственное кодирование на C ++.
QML обрабатывается во время выполнения. В рамках этой структуры все может работать вместе, различия только добавляют гибкости процессу принятия решений архитектором программного обеспечения.