Comments 56
У меня вопрос — signals: это фишка компилятора или самого Qt. Просто интересно стало.
фишка Qt
Это фишка Qt. Сигналы потом преобразовываются в обычные функции, которые обрабатываются уже мета-объектом.
Это, своего рода, расширение языка от Qt. Для того что бы это работало, необходимо перед c++ компилятором натравить на исходники moc (Meta Object Compiler), являющийся частью Qt.
>Для того что бы это работало, необходимо перед c++ компилятором натравить на исходники moc (Meta Object Compiler), являющийся частью Qt.
У читателей может сложиться впечатление, что это нужно делать руками ;)
Все необходимые телодвижения с moc, uic (который генерирует GUI из XML-файлов, созданных в Дизайнере), компиляцией ресурсов и локализаций — всё это делается незаметно для пользователя, с помощью qmake.
У читателей может сложиться впечатление, что это нужно делать руками ;)
Все необходимые телодвижения с moc, uic (который генерирует GUI из XML-файлов, созданных в Дизайнере), компиляцией ресурсов и локализаций — всё это делается незаметно для пользователя, с помощью qmake.
Увы, во времена qmake, мне не приходилось еще Qt использовать на уровне c++…
А вот во времена Qt 1.44 — точно помню, надо было правила в Makefile-ы писать, для преобразования .cpp в moc.cpp.
А вот во времена Qt 1.44 — точно помню, надо было правила в Makefile-ы писать, для преобразования .cpp в moc.cpp.
Ну не обязптельно qmake. На базе cmake`а можно создать qt проект и cmake тоже сам будет moc вызывать, да и прочие сборочные системы поддаются обучению. Но мне cmake милее всех:)
Можно, конечно, и CMake использовать, и другие системы (у меня у самого есть Qt-проект на CMake), но для него всё же приходится совершать дополнительные телодвижения (QT4_WRAP_UI, QT4_AUTOMOC и так далее). А для qmake этого не надо — он сам найдёт среди хедеров и сорцов те, которые нужно «мокнуть» и «мокнет» без дополнительного напоминания.
В этом и состоит разница между универсальным и специализированным инструментами :)
В этом и состоит разница между универсальным и специализированным инструментами :)
а я так и не понял в чем cmake может выиграть перед qmake. Ведь с qmake чтобы собрать программу на qt нам надо сделать лишь несколько простых действий.
qmake
make
а для cmake приходится еще CMakeList.txt писать и постоянно дополнять.
Может вы проясните в чем плюсы одного перед другим?
qmake
make
а для cmake приходится еще CMakeList.txt писать и постоянно дополнять.
Может вы проясните в чем плюсы одного перед другим?
помимо няшного вывода сборки ^_^
Перед qmake надо сделать qmake -project, а потом руками вычищать то, что не надо было добавлять в проект и постоянно дополнять тем, что надо.
CMake предоставляет гораздо больше возможностей. От проверки наличия различных библиотек и запроса номера SVN-ревизии до сборки готовых пакетов (с расширением CPack). Причём в зависимости от платформы по одному и тому же конфигу будет собираться deb, rpm или инсталлятор для Windows.
CMake предоставляет гораздо больше возможностей. От проверки наличия различных библиотек и запроса номера SVN-ревизии до сборки готовых пакетов (с расширением CPack). Причём в зависимости от платформы по одному и тому же конфигу будет собираться deb, rpm или инсталлятор для Windows.
o_O как…
а вы не в курсе, qtcreator поддерживает автообновление файла CMakeList.txt при обновлении проекта?
а вы не в курсе, qtcreator поддерживает автообновление файла CMakeList.txt при обновлении проекта?
Да действительно cmake более фичаст. Кроме того qmake -project в чистом виде годится только для простых qt-only программ. А если по человечески делать то разницы нет. Что .pro редактировать, что Cmakelists.txt. Кроме того cmake умеет программы инсталировать, больше генераторов, больше библиотек знает. Ну и универсален конечно.
>Перед qmake надо сделать qmake -project, а потом руками вычищать то, что не надо было добавлять в проект и постоянно дополнять тем, что надо.
Не обязательно. Можно дописывать руками, как и в CMakeLists.txt. Просто .pro, как я уже сказал, сам делает кое-что из того, для чего в CMakeLists.txt нужно специально писать команды (но это издержки разницы подходов «универсальность-заточенность»).
>CMake предоставляет гораздо больше возможностей. От проверки наличия различных библиотек....
Открою секрет: qmake тоже умеет проверять библиотеки. Более того: даже умудряется проверять их версии. У меня в рабочем проекте, к примеру, в .pro файле определяется, какая версия EDS стоит, и в зависимости от этого делает те или иные вещи.
Насчёт остального — а линком не побалуете? А то я для проверки svn-ревизии вызываю и парсю «svn info» %)
Про пакеты, кстати, тоже очень заинтересовало.
Не обязательно. Можно дописывать руками, как и в CMakeLists.txt. Просто .pro, как я уже сказал, сам делает кое-что из того, для чего в CMakeLists.txt нужно специально писать команды (но это издержки разницы подходов «универсальность-заточенность»).
>CMake предоставляет гораздо больше возможностей. От проверки наличия различных библиотек....
Открою секрет: qmake тоже умеет проверять библиотеки. Более того: даже умудряется проверять их версии. У меня в рабочем проекте, к примеру, в .pro файле определяется, какая версия EDS стоит, и в зависимости от этого делает те или иные вещи.
Насчёт остального — а линком не побалуете? А то я для проверки svn-ревизии вызываю и парсю «svn info» %)
Про пакеты, кстати, тоже очень заинтересовало.
1) FindSubversion
Subversion_WC_INFO( ${PROJECT_ROOT} SVN )
ADD_DEFINITIONS( -DREVISION="${SVN_WC_REVISION}" )
2) CPack — то ли расширение, то ли отдельная тулза, продолжающая идеи CMake в направлении автоупаковки. Сам только начал разбираться.
Subversion_WC_INFO( ${PROJECT_ROOT} SVN )
ADD_DEFINITIONS( -DREVISION="${SVN_WC_REVISION}" )
2) CPack — то ли расширение, то ли отдельная тулза, продолжающая идеи CMake в направлении автоупаковки. Сам только начал разбираться.
Красивое решение, не стали городить миллион строк препроцессорных директив, а просто добавили нужную функциональность через расширение, возьму на заметку.
Некоторые фреймворки вполне успешно реализуют то же самое на С++ вполне элегантно (пример здесь).
UFO just landed and posted this here
Qt рулез. После того как на нее подсел — видеть ничего не хочу больше :)
Ну почему же, wxWidgets тоже неплох.
Честно, сидел на нем. Но не дотягивает уже к сожалению.
Уй, ну вы что? Это же невозможно сравнивать. wx как был десять лет назад набором плохо слепленных оберток с ограниченной функциональностью, наполненной багами и несовместимостями, так и остался.
Когда я увидел документацию — закричал и выбросил монитор в окно.
Не надо, на мой взгляд, в wxWidgets документация в три с половиной раза лучше, чем у Qt.
Для сравнения, как оформленны описания почти одинаковых по логике объектов в обоих тулкитах:
qt.nokia.com/doc/4.6-snapshot/qobject.html
docs.wxwidgets.org/stable/wx_wxobject.html#wxobject
ИМХО у Qt документация более читабельна. И охватывает различные моменты использования более полно.
qt.nokia.com/doc/4.6-snapshot/qobject.html
docs.wxwidgets.org/stable/wx_wxobject.html#wxobject
ИМХО у Qt документация более читабельна. И охватывает различные моменты использования более полно.
Только стоит страшных денех :)
С версии Qt 4.5 LGPL / Free версия позволяет разрабатывать коммерческий продукт абсолютно бесплатно. Коммерческая предоставляет лишь поддержку от тролей.
Устал уже повторять.
Устал уже повторять.
А либы для других языков? Например, PyQT тоже стала LGPL?
тада! www.pyside.org/about/
PyQt — самостоятельный проект, разрабатывающийся совсем другой компанией, но Вы говорите так, как будто это именно Qt «стоит страшных денех», а не PyQt.
А вопросы насчёт стоимости PyQt — к компании Riverbank Computing :) Проскакивала информация, что Нокия начала свой проект PySide (ссылка выше) именно потому, что устала уговаривать RB выпустить PyQt под LGPL.
А вопросы насчёт стоимости PyQt — к компании Riverbank Computing :) Проскакивала информация, что Нокия начала свой проект PySide (ссылка выше) именно потому, что устала уговаривать RB выпустить PyQt под LGPL.
Меня интересует совокупная стоимость использования технологии. Совсем недавно проскакивали цифры стоимости использования QT для разработки своих программ. Там получалось все очень невесело.
Если ситуация изменилась в сторону LGPL, то это очень хорошо.
Если ситуация изменилась в сторону LGPL, то это очень хорошо.
>Меня интересует совокупная стоимость использования технологии. Совсем недавно проскакивали цифры стоимости использования QT для разработки своих программ.
«Стоимость использования Qt для разработки своих программ» с марта 2009 года равняется 0 (нулю). Цифры, о которых Вы говорите, либо безнадёжно устарели (и учитывают коммерческую лицензию), либо включают в себя не только Qt, но и ещё некоторый набор средств. Почему при этом общая сумма объявляется «стоимостью использования Qt» — для меня загадка.
Поймите уже: PyQt — это не часть Qt (не «либа для другого языка», как Вы выразились), это другая технология (разработанная другой компанией). Со своей собственной стоимостью, никак не относящейся к «стоимости Qt».
«Стоимость использования Qt для разработки своих программ» с марта 2009 года равняется 0 (нулю). Цифры, о которых Вы говорите, либо безнадёжно устарели (и учитывают коммерческую лицензию), либо включают в себя не только Qt, но и ещё некоторый набор средств. Почему при этом общая сумма объявляется «стоимостью использования Qt» — для меня загадка.
Поймите уже: PyQt — это не часть Qt (не «либа для другого языка», как Вы выразились), это другая технология (разработанная другой компанией). Со своей собственной стоимостью, никак не относящейся к «стоимости Qt».
Где же было QPropertyAnimation пол года назад?
Мне пришлось писать что-то подобное,
я писал сначала визуальный объект, а потом класс который содержал все Property объекта,
и функцию какой передавалось две переменных с разными свойствами,
в результате возвращается новый класс свойств в котором уже обработаны промежуточные значения между теми двумя входными переменными по определенной функции обработки.
Пол года назад это мне бы намного сэкономило время :)
Желающие посмотреть на один из объектов на базе моего механизма смотрите тут: www.youtube.com/watch?v=C-0jDSsBoDA&feature=player_embedded#t=40
Мне пришлось писать что-то подобное,
я писал сначала визуальный объект, а потом класс который содержал все Property объекта,
и функцию какой передавалось две переменных с разными свойствами,
в результате возвращается новый класс свойств в котором уже обработаны промежуточные значения между теми двумя входными переменными по определенной функции обработки.
Пол года назад это мне бы намного сэкономило время :)
Желающие посмотреть на один из объектов на базе моего механизма смотрите тут: www.youtube.com/watch?v=C-0jDSsBoDA&feature=player_embedded#t=40
Думаю, многие пытались сами писать подобные вещи. Я ещё на Qt3 в одном проекте пытался какую-никакую анимацию изображать. Году этак в 2004-м… :)
Пол года назад это было в Solutions, а еще раньше в Labs ;) Иногда полезно туда заглядывать, достаточно интересных проектов и разработок там.
на руки демонстранта страшно смотреть, у него буд-то паралич (
опс, это комментарий к этому видео www.youtube.com/watch?v=C-0jDSsBoDA&feature=player_embedded#t=40
Прикольно!
Вот только не нужно было мне спать на лекциях по прикладной теории цифровых автоматов: посмотрел исходники Вашего усовершенствованного проекта и запутался в состояниях :(
Такой вопрос: если сделать в автомате пару тысяч состояний (без анимации, естественно), как это скажется на производительности?
P.S. Спасибо за статью.
Вот только не нужно было мне спать на лекциях по прикладной теории цифровых автоматов: посмотрел исходники Вашего усовершенствованного проекта и запутался в состояниях :(
Такой вопрос: если сделать в автомате пару тысяч состояний (без анимации, естественно), как это скажется на производительности?
P.S. Спасибо за статью.
И еще вопрос: как сделать так, чтобы во второй версии Вашей программы «выезжающая» картинка была поверх «заезжающей»? Добавить к состоянию еще одно свойство?
О, и еще: для чего может использоваться безусловный переход состояний?
О, и еще: для чего может использоваться безусловный переход состояний?
>И еще вопрос: как сделать так, чтобы во второй версии Вашей программы «выезжающая» картинка была поверх «заезжающей»?
Думаю, нужно каким-то образом расположить выезжающий на самый верх стека виджетов (так называемый z-index им назначается в порядке из создания). Если честно, такой проблемой ни разу не заморачивался.
>О, и еще: для чего может использоваться безусловный переход состояний?
Если мы, к примеру, захотим, чтобы картинка сначала выехала, а потом изменила размер, то разносим это по двум разным состояниям, и переход между ними делаем безусловным. Получится так: кликаем — пошёл процесс перемещения, после завершения которого сразу же начнётся процесс изменения размера без повторного клика.
Думаю, нужно каким-то образом расположить выезжающий на самый верх стека виджетов (так называемый z-index им назначается в порядке из создания). Если честно, такой проблемой ни разу не заморачивался.
>О, и еще: для чего может использоваться безусловный переход состояний?
Если мы, к примеру, захотим, чтобы картинка сначала выехала, а потом изменила размер, то разносим это по двум разным состояниям, и переход между ними делаем безусловным. Получится так: кликаем — пошёл процесс перемещения, после завершения которого сразу же начнётся процесс изменения размера без повторного клика.
Замечательная статья.
Скажите, а в чём преимущество использования QStateMachine перед стандартным connect?
Скажите, а в чём преимущество использования QStateMachine перед стандартным connect?
В том что это более логичный и абстрактный способ описания зависимостей переходов интерфейса из одного состояния в другое, при наступлении определенных событий. Избавляет от рутины в виде создания кучи сигналов/слотов и связывания их. Эту задачу на себя берет QStateMachine. А еще лучше посмотреть документацию по нему, там есть примеры различных моделей конечного автомата, которые можно реализовать, и не все тривиальны, но легко укладываются в логику.
Пользовательские сигналы/слоты всё равно вручную писать придётся. А в случае стандартных сигналов/слотов для connect тоже ничего не надо было добавлять.
Т.е., я почему спросил, потому что я так понимаю, что объём работы и там и там однаков.
Дело только в том, что конечный автомат идеологически более правильное и красивое решение. А технически и функционально никаких отличий от connect'a я не вижу.
Т.е., я почему спросил, потому что я так понимаю, что объём работы и там и там однаков.
Дело только в том, что конечный автомат идеологически более правильное и красивое решение. А технически и функционально никаких отличий от connect'a я не вижу.
IMHO не совсем одинаковое количество:
Случайно отправилось :(
Вот сколько бы нужно было писать кода чтобы реализовать следующий автомат без использования данного фреймворка :
Вот сколько бы нужно было писать кода чтобы реализовать следующий автомат без использования данного фреймворка :
>Т.е., я почему спросил, потому что я так понимаю, что объём работы и там и там однаков.
Не совсем. В случае state machine количество сигналов равно количеству переходов и никак не зависит от количества объектов. В случае ручных коннектов Вам нужно будет добавлять коннекты для каждого нового объекта.
Или я не до конца понял Вашу мысль?
Не совсем. В случае state machine количество сигналов равно количеству переходов и никак не зависит от количества объектов. В случае ручных коннектов Вам нужно будет добавлять коннекты для каждого нового объекта.
Или я не до конца понял Вашу мысль?
Sign up to leave a comment.
Пробуем Qt 4.6: Qt Animations и State Machine