Для нового возможного проекта мы подумываем о Qt как об основном фреймворке для разработки приложения. Qt для нас малознаком, никакого опыта нет. В фоновом режиме я поглядел немного видео и сразу возникли вопросы. Планируется десктопное приложение, преимущественно под винду, возможно и под линух (пока непонятны перспективы), когда-нибудь в будущем возможны поддержка тачскринов и даже планшетная версия. Qt будет использоваться для написания gui. Основная бизнес-логика уже написана на C++, среда разработки VS. Пользователи — всякие CAD/CAE инженеры и приравненные к ним )
— компиляция кода, использующего непосредственно Qt, только через фреймворк Qt? Или только гуи (где сигналы/слоты)? А где нет Qt-дополнений языка — там можно разрабатывать и компилировать как обычно в студии?
— как имплементировано гуи для Винды: окна(диалоги/контролы) полностью рисуют сами или через окна WindowsAPI?
— и отсюда же вопрос: какова вообще практика поддержки во фреймворке всяких новых фишек от новых версий винды? ну там, внешний вид, прогрессы, тулбары,... Автоматически поддерживается или требует времени на реализацию?
— возможно я ошибся, но мне показалось что Qt сам рисует гуи. Тогда каким образом осуществляется автоматизация тестирования ГУИ? Наша система тестирования все же заточена под виндовые окна.
— какова совместимость в смысле одновременной работы Qt-гуи и гуи на других фреймворках (MFC, чистый WindowsAPI)? Т.е, возможно ли в большом MFC-приложении через развитое АПИ подключить беспроблемный запуск qt-диалога (реализованного в отдельной длл)?
— ну и наоборот, можно ли в Qt-приложении запустить MFC-диалог? А встроить (embed) MFC-окно непосредственно в каркас Qt-приложения (например, через сабклассинг)?
Здравствуйте, RikkiTikkiTavi, Вы писали:
RTT>- компиляция кода, использующего непосредственно Qt, только через фреймворк Qt? Или только гуи (где сигналы/слоты)? А где нет Qt-дополнений языка — там можно разрабатывать и компилировать как обычно в студии?
Ставится плагин для студии и вся работа с Qt и не Qt идет в одном проекте. RTT>- как имплементировано гуи для Винды: окна(диалоги/контролы) полностью рисуют сами или через окна WindowsAPI? RTT>- и отсюда же вопрос: какова вообще практика поддержки во фреймворке всяких новых фишек от новых версий винды? ну там, внешний вид, прогрессы, тулбары,... Автоматически поддерживается или требует времени на реализацию?
Автоматически, через стили можно очень сильно изменить вид.
Qt uses the native graphics API of each platform it supports, taking full advantage of system resources.
RTT>- возможно я ошибся, но мне показалось что Qt сам рисует гуи. Тогда каким образом осуществляется автоматизация тестирования ГУИ? Наша система тестирования все же заточена под виндовые окна.
У нас куплен Squish RTT>- какова совместимость в смысле одновременной работы Qt-гуи и гуи на других фреймворках (MFC, чистый WindowsAPI)? Т.е, возможно ли в большом MFC-приложении через развитое АПИ подключить беспроблемный запуск qt-диалога (реализованного в отдельной длл)? RTT>- ну и наоборот, можно ли в Qt-приложении запустить MFC-диалог? А встроить (embed) MFC-окно непосредственно в каркас Qt-приложения (например, через сабклассинг)?
Скорей всего можно, но смысла так делать не вижу.
RTT>- компиляция кода, использующего непосредственно Qt, только через фреймворк Qt? Или только гуи (где сигналы/слоты)? А где нет Qt-дополнений языка — там можно разрабатывать и компилировать как обычно в студии?
можно проекты хранить (SVN) в формате qmake и создавать проекты для VC перед тем как работать в студии. Довольно удобно.
RTT>- как имплементировано гуи для Винды: окна(диалоги/контролы) полностью рисуют сами или через окна WindowsAPI?
Сейчас есть два типа UI: 1. базирующиеся на QWidget и 2. QML — это новое (смесь JSON + JavaScript). 1й пытается использовать нативные контролы, а 2й рисует всё сам.
RTT>- и отсюда же вопрос: какова вообще практика поддержки во фреймворке всяких новых фишек от новых версий винды? ну там, внешний вид, прогрессы, тулбары,... Автоматически поддерживается или требует времени на реализацию?
всё руками или ждать.
RTT>- возможно я ошибся, но мне показалось что Qt сам рисует гуи. Тогда каким образом осуществляется автоматизация тестирования ГУИ? Наша система тестирования все же заточена под виндовые окна.
Squish или же самим писать юнит-тесты с помощью QTest. муторно, но можно довольно много чего понаписать.
RTT>- какова совместимость в смысле одновременной работы Qt-гуи и гуи на других фреймворках (MFC, чистый WindowsAPI)? Т.е, возможно ли в большом MFC-приложении через развитое АПИ подключить беспроблемный запуск qt-диалога (реализованного в отдельной длл)?
отсутствует совместимость. Не получится смешивать MFC и Qt.
RTT>- ну и наоборот, можно ли в Qt-приложении запустить MFC-диалог? А встроить (embed) MFC-окно непосредственно в каркас Qt-приложения (например, через сабклассинг)? RTT>
Здравствуйте, RikkiTikkiTavi, Вы писали:
RTT>- компиляция кода, использующего непосредственно Qt, только через фреймворк Qt? Или только гуи (где сигналы/слоты)? А где нет Qt-дополнений языка — там можно разрабатывать и компилировать как обычно в студии?
qmake генерирует проект для студии.
RTT>- как имплементировано гуи для Винды: окна(диалоги/контролы) полностью рисуют сами или через окна WindowsAPI?
Рисуют сами
RTT>- и отсюда же вопрос: какова вообще практика поддержки во фреймворке всяких новых фишек от новых версий винды? ну там, внешний вид, прогрессы, тулбары,... Автоматически поддерживается или требует времени на реализацию?
сейчас налицо тенденция перехода на QtQuick (QML). Как бы нативные фишки винды вообще побоку.
RTT>- возможно я ошибся, но мне показалось что Qt сам рисует гуи. Тогда каким образом осуществляется автоматизация тестирования ГУИ? Наша система тестирования все же заточена под виндовые окна.
Qt с открытым кодом. Пишете свою тестилку, вкручиваете в Qt и собираете отдельную сборку Qt для тестирования.
RTT>- какова совместимость в смысле одновременной работы Qt-гуи и гуи на других фреймворках (MFC, чистый WindowsAPI)? Т.е, возможно ли в большом MFC-приложении через развитое АПИ подключить беспроблемный запуск qt-диалога (реализованного в отдельной длл)? RTT>- ну и наоборот, можно ли в Qt-приложении запустить MFC-диалог? А встроить (embed) MFC-окно непосредственно в каркас Qt-приложения (например, через сабклассинг)?
QtWinMigrate — позволяет запустить в mfc окне qt widget и наоборот. Но лучше так не делать, гемор еще тот, например нужно будет создать экземпляр QApplication.
RTT>Заранее благодарю за помощь!
PS
обратите внимание на мою подпись.
RTT>— компиляция кода, использующего непосредственно Qt, только через фреймворк Qt? Или только гуи (где сигналы/слоты)? А где нет Qt-дополнений языка — там можно разрабатывать и компилировать как обычно в студии?
Cmake тоже можно использовать. А так да, в кьюте используется qmake скрипт которого зашит в проект.
RTT>— как имплементировано гуи для Винды: окна(диалоги/контролы) полностью рисуют сами или через окна WindowsAPI?
Qt берет нативное апи. Есть так же возможность рисовать во фреймбуффер линукса, если будет нужда отказаться от иксов и использовать голое ядро.
RTT>— какова совместимость в смысле одновременной работы Qt-гуи и гуи на других фреймворках (MFC, чистый WindowsAPI)? Т.е, возможно ли в большом MFC-приложении через развитое АПИ подключить беспроблемный запуск qt-диалога (реализованного в отдельной длл)?
А че нет, подключить библиотеки кьюта придеться и тащить их за собой.
RTT>— ну и наоборот, можно ли в Qt-приложении запустить MFC-диалог? А встроить (embed) MFC-окно непосредственно в каркас Qt-приложения (например, через сабклассинг)?
Можно почитать это. А вообще, это открытый опенсорсный проект и лучше задать вопросы непосредственно создателям. Там развитое сообщество.
Есть джаббер сервер с румами, где можно пообщаться. А так же форумы.
Здравствуйте, RikkiTikkiTavi, Вы писали:
RTT>- как имплементировано гуи для Винды: окна(диалоги/контролы) полностью рисуют сами или через окна WindowsAPI?
В большинстве случаев Qt все отрисовывает сама. Вы можете использовать нативные виндовые диалоги для стандартных операций (типа выбора файла), если будете использовать соответствующие стаические функции (например, QFileDialog::getOpenFileName). В моем представлении, в этом случае все будет работать быстрее, но в этом случае затрудниться тестирование этих виндовых диалогов, если тестовая библиотека заточена именно под Qt.
RTT>- какова совместимость в смысле одновременной работы Qt-гуи и гуи на других фреймворках (MFC, чистый WindowsAPI)? Т.е, возможно ли в большом MFC-приложении через развитое АПИ подключить беспроблемный запуск qt-диалога (реализованного в отдельной длл)? RTT>- ну и наоборот, можно ли в Qt-приложении запустить MFC-диалог? А встроить (embed) MFC-окно непосредственно в каркас Qt-приложения (например, через сабклассинг)?
Даже при использовании QtWinMigrate и QWinWidget следует готовиться к большому объему работы. Вам предстоит скрестить разные циклы выборки сообщений, привязаться к нужным виндовым событиям и игнорировать сообщения МФС об утечках памяти, поскольку она не умеет их нормального отслеживать для Qt объектов. Относительно стабильно такое скрещивание ежа и ужа работает только на Qt4. Qt5 в этом плане все еще сыровата. Насколько стабильно будет даже с qt4 для 64 бит — неизвестно. Вот здесь и здесь есть небольшие примеры.
Здравствуйте, RikkiTikkiTavi, Вы писали:
RTT>Добрый день!
Добрый, тут уже много наотвечали. Добавлю отсебятины:
RTT>- компиляция кода, использующего непосредственно Qt, только через фреймворк Qt? Или только гуи (где сигналы/слоты)? А где нет Qt-дополнений языка — там можно разрабатывать и компилировать как обычно в студии?
CMake достаточно неплохо дружит с Qt. Но если вы windows-only, то можно использовать стандарные солюшены от MSVC + Qt Addin. Qt Addin будет автоматически создавать правила для компиляции исходников, которые используют функционал Qt. Т.е. для пользователя всё выглядит прозрачно: добавили файл (add file, add class wizard и пр.), и всё работает из коробки. Плюс Qt addin добавляет правила компиляции для таких кутэшных вещей, как .ui файлы (формы), .qrc (ресурсы) и пр. Плюс добавляет хинты отладчику, чтобы можно было на лету просматривать содержимое кутэшных объектов.
RTT>- как имплементировано гуи для Винды: окна(диалоги/контролы) полностью рисуют сами или через окна WindowsAPI?
Qt не использует наитивные окна, за исключением окон верхних уровней (и менюшек/popup окон). Т.е. у кнопки не получится взять HWND. Но в то же время, по умолчанию, для рендеринга кнопок используются функции WinAPI, т.е. все контролы будут выглядеть как родные.
RTT>- и отсюда же вопрос: какова вообще практика поддержки во фреймворке всяких новых фишек от новых версий винды? ну там, внешний вид, прогрессы, тулбары,... Автоматически поддерживается или требует времени на реализацию?
Использовать WinAPI внутри можно без проблем, но в большинстве случаев это не нужно. Для доступа к реестру есть класс QSettings. Для доступа ко всяким фичам оконных менеджеров есть QtWinExtras. Все стандартные диалоги (мессаджбоксы, выбор папки/файла, выбор цвета) имеют кутэшные врапперы, которые вызывают наитивные диалоги. Но можно использовать + кастомизировать и аналоги из Qt.
RTT>- возможно я ошибся, но мне показалось что Qt сам рисует гуи. Тогда каким образом осуществляется автоматизация тестирования ГУИ? Наша система тестирования все же заточена под виндовые окна.
Про Squish уже написали. Сам не пробовал, но видел, как он работает. Был недавно на конфе Qt Developers Days in Berlin. Впечатлило.
RTT>- какова совместимость в смысле одновременной работы Qt-гуи и гуи на других фреймворках (MFC, чистый WindowsAPI)? Т.е, возможно ли в большом MFC-приложении через развитое АПИ подключить беспроблемный запуск qt-диалога (реализованного в отдельной длл)?
Если сильно не писать своих циклов обработки сообщений, то юзать WinAPI можно без проблем. Плюс есть классы, облегчающие портирование (как писали выше). Но на практике, мы промучались где-то месяц и решили переписывать GUI часть проекта с нуля на Qt. Благо код был качественно написан и отделить логику от UI получилось легко.
RTT>- ну и наоборот, можно ли в Qt-приложении запустить MFC-диалог? А встроить (embed) MFC-окно непосредственно в каркас Qt-приложения (например, через сабклассинг)?
Здравствуйте, visual_wind, Вы писали: _>Даже при использовании QtWinMigrate и QWinWidget следует готовиться к большому объему работы. Вам предстоит скрестить разные циклы выборки сообщений, привязаться к нужным виндовым событиям и игнорировать сообщения МФС об утечках памяти, поскольку она не умеет их нормального отслеживать для Qt объектов. Относительно стабильно такое скрещивание ежа и ужа работает только на Qt4. Qt5 в этом плане все еще сыровата. Насколько стабильно будет даже с qt4 для 64 бит — неизвестно. Вот здесь и здесь есть небольшие примеры.
Спасибо за подсказки и ссылки!
Конечно, смущает "2009" и "Qt 4.4, 4.5". Это больше не развивается?
Здравствуйте, RikkiTikkiTavi, Вы писали:
RTT>Конечно, смущает "2009" и "Qt 4.4, 4.5". Это больше не развивается?
Не развивается. Новых билдов Qt4 не будет, за исключением нахождения там какик-либо критических багов. Что очень маловероятно.
QtSolutions о которых вам говорят — тоже не развивают, т.к. это практически никому не нужно.
Мфц сам по себе сплошной глюк, а если скрестить его с кутэ — то вообще завязните в отладке.
Еще про версии подскажите плз.
Про 5ю версию часто встречаются нарекания (по сравнению с 4й). С другой же стороны, очевидно, что за ней будущее.
4я же версия вроде как считается стабильной? Вроде бы даже чуток поддерживается еще (последнее обновление 24 апреля).
Насколько сильна между ними разница (если не брать в расчет QML, а смотреть на "базовые" вещи)?
Насколько трудоемка миграция 4 -> 5 ?
Здравствуйте, SaZ, Вы писали: SaZ>Не развивается. Новых билдов Qt4 не будет, за исключением нахождения там какик-либо критических багов. Что очень маловероятно. SaZ>QtSolutions о которых вам говорят — тоже не развивают, т.к. это практически никому не нужно. SaZ>Мфц сам по себе сплошной глюк, а если скрестить его с кутэ — то вообще завязните в отладке.
Спасибо.
Видимо, на шаринг гуи лучше не расчитывать и идти по другому пути...
Здравствуйте, RikkiTikkiTavi, Вы писали:
RTT>... RTT>Насколько сильна между ними разница (если не брать в расчет QML, а смотреть на "базовые" вещи)?
Начинать что-то делать на 4-й смысла нет, т.к. он более не развивается. В 5-й версии выкосили весь legacy код от Qt3 и сделали более грамотный апи. Плюс, заложили в архитектуру многомониторность, dpi-scaling и другие полезные вещи. Плюс, фиксят баги, которые появляются с выходом обновлений для OS. В своё время долго тр**ались с кутэ, когда она отказалась корректно сохранять настройки нашего приложения, без админских прав, в макоси. Плюс, 5-й кутэ старается поддерживать новые компиляторы.
Единственное исключение, когда вам вообще может понадобиться 4-й кутэ — это если вы пишите что-то под железо, для которого не реализован порт 5-го кутэ.
RTT>Насколько трудоемка миграция 4 -> 5 ? RTT>Спасибо
Кратко расскажу про миграцию проекта, на котором сейчас работаю (редактор карт для wotblitz, платформы OS X, Win):
1) подправил cmake для подключения всех нужных модулей 5-й кутэ, т.к. в пятёрке модульность реализована лучше и нужно всё подключать ручками.
2) заменил QString::toAscii на QString::toLatin1 (для бэкэнда строк в 5-м кутэ используется ICU, а не самописный велосипед)
3) заюзал пару инклюдов (QtConcurrent, QMetaType и ещё что-то) там где это надо было
4) заменил через Ctrl+H макросы Q_WS_* на Q_OS_*
5) заменил пару вызовов методов QHeaderView, т.к. незначительно поменялось API
6) переделываю код QWidget::winEvent на QWidget::nativeEvent, о чём рядом упомянул
.
7) нужно будет подправить инструменты для деплоймента, ибо для 5-го кутэ он немого сложнее
Если не учитывать пункт 6, то на всё ушло меньше рабочего дня. Но он очень специфичен. По факту мы вообще решили отказаться от платформозависимого куска в кутэ части.
Здравствуйте, RikkiTikkiTavi, Вы писали:
RTT>Насколько сильна между ними разница (если не брать в расчет QML, а смотреть на "базовые" вещи)? RTT>Насколько трудоемка миграция 4 -> 5 ?
1) Правка заголовочных файлов, qtwidgets, printsupport, и т.д.
2) Правка инсталятора, windowsprintersupport.dll — эту dll долго не включали
3) Самая большая проблема перевод исходников на utf-8 (у меня в коде tr( "русский текст" ) есть), сделали скриптом + свой Translator
В общем если с переводами все нормально то за день, два можно перейти, а я после перехода еще недели 2-3 вылавливал места где неправильно tr был написан.
Здравствуйте, EXL, Вы писали:
SaZ>>для бэкэнда строк в 5-м кутэ используется ICU, а не самописный велосипед
EXL>В Qt5 однажды собирались как раз выкинуть жирнющий ICU, точнее убрать зависимость QtCore от ICU. Но как-то не срослось. EXL>http://qt-project.org/wiki/Qt-5-ICU
Можно при configure использовать -no-icu флаг.
