Сообщение Re: Общие вопросы по Qt от 21.10.2014 9:17
Изменено 21.10.2014 9:19 SaZ
Здравствуйте, 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. Для доступа ко всяким фичам оконных менеджеров есть <tt>QtWinExtras</tt>. Все стандартные диалоги (мессаджбоксы, выбор папки/файла, выбор цвета) имеют кутэшные врапперы, которые вызывают наитивные диалоги. Но можно использовать + кастомизировать и аналоги из 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-приложения (например, через сабклассинг)?
Можно, но только в Qt4. Гемморой ещё тот.
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. Для доступа ко всяким фичам оконных менеджеров есть <tt>QtWinExtras</tt>. Все стандартные диалоги (мессаджбоксы, выбор папки/файла, выбор цвета) имеют кутэшные врапперы, которые вызывают наитивные диалоги. Но можно использовать + кастомизировать и аналоги из 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-приложения (например, через сабклассинг)?
Можно, но только в Qt4. Гемморой ещё тот.
Re: Общие вопросы по Qt
Здравствуйте, 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-приложения (например, через сабклассинг)?
Можно, но только в Qt4. Гемморой ещё тот.
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-приложения (например, через сабклассинг)?
Можно, но только в Qt4. Гемморой ещё тот.