Qt *

В данном уроке я расскажу в картинках как собрать приложение статически/провести статическую линковку/ отучить ваш *.exe от библиотек Qt — кажется это всё одно и тоже по своей сути

Вступление:

Лично я всё проделывал со свеженькой на данный момент Qt SDK с сайта Nokia( Qt 4.8 и SDK 1.2.1)
Сам я полный нуб в Windows, так как всё жизнь сижу на Linux, так что всё сопровождается картинками, для таких же нубов в винде, как я сам.

Многие из тех кто занимаются разработкой на C++/Qt знакомы с такой средой как Qt Creator, создатели которой потрудились над дизайном не меньше чем над функциональностью. Но меня, как любителя темных цветовых схем и плоского минимализма, всегда не устраивали светлый фон панелек и градиентные заголовки.

Казалось бы, открытый исходный код — бери да меняй, но неопытность и лень останавливали меня, пока я не узнал про такую вещь как Qt Style Sheets, позволяющюю описать вид виджетов в формате css.

Мы с Vass записали и выложили первую серию второго сезона подкаста «Заметки о Qt».

Сам подкаст на rpod.ru — qt-notes.rpod.ru/284337.html
Теперь с конкурсом!

Приходилось часто работать с классом QDataStream. В результате накопил некоторый опыт, как правильно его использовать.

Добрый день всем. В этой статье я опишу свой практический опыт проектирования системы авторизации, в частности на C++ Qt 4. Для многих опытных программистов покажется все нижеизложенное банальностью, но для начинающих свой путь программистов, данный опыт думаю, будет полезен. Слов минимум, в основном вырезки кода.

Привет, хабражители!

Сейчас какой-то спец с многолетним опытом работы с Qt подумал: «Что за фигня? Хабр — для вещей покруче!». Но ведь даже спецам с многолетним опытом иногда надо читать вот такие статьи про простые вещи, ведь это — важно. Код — это одна из самых важных составляющих программирования. А наша задача — держать его в чистоте. Эта статья посвящена всем Qt программистам которые стремятся к идеалу.

Конечно есть статья на Qt Project — Qt Coding Style. Только вот там материала ценного меньше…

В недавнем проекте с Qt пришлось разбираться с классом QThread. В результате вышел на «правильную» технологию работы c QThread, которую буду использовать в других проектах.

Этот пост является продолжением данной (в переводе) статьи.

В предыдущем посте мы рассмотрели, как движок QML загружает файлы. Напомню, что сначала QML-файлы разбираются парсером, затем компилируются в промежуточный байт-код и наконец следуя инструкция байт-кода, для каждого эемента в каждом QML-файле создаётся C++ объект. Например, мы видели, что когда QML файл содержит элемент Text, то движок создает экземпляр C++ класса QQuickText.

На самом деле, загрузка файлов — это почти всё, чем занимается движок QML. После загрузки, он перестаёт вмешиваться в процесс работы приложения. Обработка событий и отрисовка элементов в Runtime полностью ложится на плечи C++. Например, элемент TextInput обрабатывает события вроде QQuickTextInput::keyPressEvent() и обновления QQuickTextInput::updatePaintNode(), без участия движка QML.

Но существуют две важные вещи, на которые движок QML всё же влияет во время выполнения: Связанные обработчики сигналов (Bound signal handlers) и обновление привязок свойств (property binding). Связанные обработчики сигналов — это такие вещи, как onClicked обработчик для MouseArea. Сегодня же мы рассмотрим привязки (Bindings).

В этой (2 часть в переводе) серии статей мы заглянем под капот движка QML и раскроем некоторые из особенностей его внутренней работы.Статьи основаны на Qt5 версия QtQuick, QtQuick 2.0.

Большинство людей знают, что каждый элемент в QML файле опирается на конкретный C++ класс. Когда QML файл загружен, движок QML как-то создает один C++ объект для всех элементов в файле. В этом посте мы рассмотрим, как движок QML переходит от чтения текстового файла, включающего полное дерево C++ объектов. В документации Qt присутствует раздел с обширным описанием взаимодействия QML и C++, прочтение которого стоит потраченного времени. В данной серии статей, я предполагаю что пользователь прочёл и понимает описанное в документации.

За последние месяцев 20 я написал немало постов о Qt5, QML Scene Graph, шейдерах и многом другом. Сейчас, когда бета-версия Qt5 уже на подходе, я думаю что пора показать очередное технологическое демо. Оно называется 'Cinematic Experience' и выглядит следующим образом:

Одним из недостатков Qt Quick API является то, что хоть рендеринг и выполняется в выделенном потоке, тем не менее наша анимация всегда работает в потоке графического интерфейса пользователя.

Запуск же анимации за пределами основного потока приложения имеет то преимущество, что значительно снижает влияние ресурсоёмких задач на анимацию, которые обычно блокируют основной поток и приводят к задержкам анимации.

Существуют три основные проблемы, препятствующие нам вынести анимацию в отдельный поток:

• Анимация обновляющаяся при изменении свойств. Свойства являются частью QObject и системы мета-объектов. Чтобы избежать безумия с потоками, нам разрешается лишь читать и писать эти свойства в потоке графического интерфейса пользователя.
• Свойства часто имеют привязки и связи в QML, которые вызывают JavaScript-код, при наступлении неких событий, который также должен выполняться в потоке GUI.
• Цикл рендера в библиотеке QtQuick завязан на поток GUI, а следовательно, когда данный поток заблокирован, анимация не обновляется.

Как известно, Qt предлагает разработчикам практически неограниченные возможности для создания интерфейсов. В большинстве случаев, если вы используйте стандартные виджеты, внешний вид вашего приложения (и элементов его интерфейса) будет соответствовать внешнему виду вашей операционной системы. Для этого в Qt есть система так называемых стилей — классов, ответственных за отрисовку стандартных элементов интерфейса. В этой статье мы попробуем создать свой стиль и применить его к простейшему приложению для того, чтобы получить красивую таблицу на основе виджета QTableWidget.

Предисловие

Всем привет. Сразу признаюсь, я начал писать данный пост уже достаточно давно, но времени полностью завершить его написание всё не хватает. Поэтому, сейчас я публикую его в текущем состоянии, а описание трёх незавершённых разделов всё же отложу и постараюсь опубликовать отдельным постом.

Введение

Это заметка, в которой я хотел бы немного описать архитектуру и систему расширений среды разработки Qt Creator. Изначально, я предполагал лишь перевести документ Writing-Qt-Cretor-plugins.pdf, но так уж вышло, что развитие Qt Creator не стоит на месте и во первых, данный документ уже не столь актуален (сам устарел, API поменялось, куски кода не полные и часто не работают), а во вторых со времени его написания появлись дополнительные возможности расширения Qt Creator, которые хотелось бы описать.

Тем не менее, не будь этого документа, не было бы и данной заметки: из него я взял очень много, вплоть до структуры поста, при этом постаравшись где-то что-то выкидывая/заменяя/добавляя сделать пост актуальным для последней на текущий момент времени версии Qt Creator 2.4.0.

Кому может быть полезен данный документ? В первую очередь это конечно же Qt-программисты, которые выбрали данную IDE как основную среду разработки.

Кроме того, благодаря продуманной системе расширений Qt Creator, данный материал будет полезен тем, кто собрался создавать собственные средства разработки, но не хотят начинать писать их с чистого листа: человек может отключить все ненужные ему расширения Qt Creator и написать свои собственные, пользуясь при этом готовыми примерами в исходниках Qt Creator.

Итак, что же нас ожидает под катом (жирным отмечены готовые разделы):

1. Сборка Qt Creator
2. Первое расширение
3. Добавление новых меню и пунктов меню
4. Архитектура Qt Creator
5. Добавление нового редактора (Editor)
6. Добавление боковой навигационной панели
7. Добавление страницы в диалог настроек
8. Добавление фильтра в диалог поиска
9. Добавление нового типа проекта

Напомню, что Qt Creator является кросс-платформенной свободной IDE для работы с фреймворком Qt, разработанной Trolltech (Nokia). Что не мешает сделать из него простой текстовый редактор с подсветкой синтаксиса, простым отключением всех расширений. Внимание, сотни картинок!

Для надежности и безопасности, часто имеет смысл разделить функционал приложения на множество небольших исполняемых файлов (демонов), вместо того, чтобы поддерживать крупное и монолитное приложение.

В своё время, Qt4 была разделена на несколько модулей, что в частности позволило создавать приложения, не требующих графического интерфейса. Благодаря сильной фокусировке на архитектуре встраиваемых систем и нескольким здравомыслящим решениям в области архитектуры, Qt5 вывела данный подход на новый уровень.

Давайте посмотрим на простую функцию:

QCoreApplication app(argc, argv);
QTimer::singleShot(3000, &app, SLOT(quit()));
return app.exec();

Это Qt-приложение, не имеющее графического интерфейса. Оно работает 3 секунды и затем завершается.

В продолжение своей статьи «Простой электронный самописец» хочу поделится опытом создания терминала для сообщения с разработанным мной девайсом на основе библиотек QSerialDevice и Qwt, ну и естественно Qt. QSerialDevice работает с любым COM-портом (реальным или виртуальным) определенным операционной системой, поэтому не имеет значения каким способом контроллер подключен к ПК: непосредственно через адаптер UART->RS-232(MAX-232), через адаптеры UART->USB(FT-232, CP2101) или UART->Bluetooth(BTM-222), также можно, например, подключить Arduino-совместимое устройство (адаптер UART->USB уже напаян на плату). Qwt же — мощное средство отображения данных. Их общий плюс — кроссплатформенность, это же Qt, достаточно скомпилировать коды под нужной платформой — и все работает! Так что, кому интересно, прошу под кат!

От переводчика: не пинайте, ждал пока кто-либо переведёт эту новость, но данного события так и не случилось, а обсудить очень хочется.

Вслед за недавним объявлением, о полном приобретении Qt у Nokia, Digia изложила свои дальнейшие планы в письме к сообществу KDE.

Директор R&D департамента Digia, Tuukka Turunen заявил, что видит будущее Qt, как лучшей кросс-платформенной среды разработки и желает наладить более тесное сотрудничество с KDE и другими партнерами в экосистеме Qt.

Полный текст письма приводится ниже.

Компания Digia официальным пресс-релизом объявила о заключении соглашения о передаче ей компанией Nokia разработки кросс-платформенного инструментария Qt. В рамках передачи работ в Digia также перейдут до 125 разработчиков Qt, в основном — сотрудники офисов Nokia Qt Software в Осло и Берлине.

Напомним, что в марте 2011 года Digia приобрела права на разработку, сопровождение и продажи коммерческой версии Qt.

Now is a good time for everyone to revisit their perception of Qt. Digia’s targeted R&D investments will bring back focus on Qt’s desktop and embedded platform support, while widening the support for mobile operating systems.

— Tommi Laitinen, SVP, International Products, Digia

Пресс-релиз с официального сайта Digia
Сообщение в блоге Nokia Qt Software

Практически в каждом проекте, встает задача персистентного чтения/записи конфигурации. Не секрет что существует большое количество уже готовых библиотек для решения этой задачи. Некоторые из-них просты, некоторые чуть сложнее в использовании.
Если же проект разрабатывается с использованием Qt, думаю нет смысла линковать дополнительную библиотеку, так как в Qt есть все средства для создания очень простого, гибкого и кроссплатформенного решения.
Как раз о таком решении хочу расказать вам в этом посте.

Nokia закрывает свой ​​Австралийский офис и собирается уволить всеx разработчиков. Бывший инженер Nokia Атлант Шмидт опубликовал сообщение в списке рассылки, что ребята из Nokia настойчиво хотят продать свои активы Qt.

Я не собирался говорить об этом, но тема возникла…
Надежный источник прошептал мне на ухо, что после того как Nokia убила Meltemi,
Себастьяну Нюстрему (старший вице-президент, отвечающий за Qt) дали задание с целью распродажи активов Qt.

Большой экперимент Nokia с фреймворками (мобильными и иными)
закончен.

Ссылка на сообщение

Как говорил Генрих VIII очередной жене, — «Я вас долго не задержу...»
Пост — небольшое расширение предыдущей статьи «Qt + OpenCV. Runtime и Widget для CvCapture (устройства видеозахвата).»
Если вас, уважаемый читатель, угораздило приобрести видеокамеру, поддержка которой не обеспечена библиотекой OpenCV, а методы работы оной с изображениями ой как нужны, не следует расстраиваться.
Сперва изучим, что нам преподнесли, или что сами, несведующие, купили.

1. Интерфейс GigE поддерживается SDK, лежащей в свободном доступе или поставленной совместно с товаром. Первый плюс!
2. Документация более-менее осмыслена. Снова повезло!
3. Примеры есть! Надо же… Плюс!

Итак, я стал «счастливчиком» по плюсикам этого списка, заполучив камеру Smartek Giganetix GC1921M
Методы SDK работают, но как-то так… Код частично закрыт. Уровень программиста стал понятен из фрагмента кода

...
if (m_selectedDevice->IsConnected()){
			m_disconnectAct->setEnabled(true);
			m_fwUpdateAct->setEnabled(true);
}
...

Если у вас возник вопрос, — «А что тут такого?», — я не смогу отправить вас на машине времени в советский вуз, где за это с вас снимут балл на экзамене. :)
Да, и ладно. Нам-то нужно, всего лишь, подключиться, принять поток и отключиться. Благо, примеры — на месте.