Russian Qt Forum

Привет, друзья! Спешу сообщить о выходе новой версии.

Для нового Qt 5.6 разработчики обещают долговременную поддержку (LTS). Предыдущим LTS релизом был Qt 4.8.

Список изменений:

• Полностью переписана поддержка hi-dpi экранов.
• Теперь, приложения Qt, основанные на плотности пикселов позволяют автоматически подстраивать размеры шрифтов, пиктограмм, элементы окон и графику.
• Webkit и Qt Quick 1 удалены.
• Новая система CI, получившая название «Coin for COntinuos INtegration»
• Уменьшение затрат памяти на использование динамических свойств
• Возможность лога непосредственно в syslog на Линуксе
• Новый класс QVersionNumber
• Множество оптимизаций в производительности QString
• Добавлен метод QHostAddress::isMulticast()
• Улучшена кроссплатформенная поддержка OpenGL ES 3.0 and 3.1
• Возможность внутреннего рендеринга 16 бит на канал
• Qt WebEngine теперь основан на Chromium 45 и поддерживает плагины pepper, включая Flash
• В Qt Nfc добавлена поддержка Android

Ураа, погздравляем.

PS особый привет Igors - оптимизация QString ^.^

 ;D ;D

Вот не могли раньше поддержку hi-dpi сделать, придется теперь все свои костыли выпиливать.

Попробовал Qt SerialBus, понравилось, все просто и понятно.
Но вот что удивляет. Для работы с устройствами есть 2 класса - QModbusRtuSerialMaster и QModbusTcpClient. Т.е., если к контроллеру подключаешься через последовательный порт, то используется протокол Modbus RTU, через Ethernet (TCP/IP) - то Modbus TCP.
А как быть, если мне нужен Modbus RTU по TCP/IP? К примеру, Moxa Nport в режиме TCP Server Mode - подключаемся к нему по Ethernet, а работаем по RTU, т.е. преобразования протокола в этом устройстве не предусмотрен - что подаешь на внешний порт, то и транслируется в сеть RS-485.
Нужен еще один класс - "QModbusRtuTcpMaster". Заглянул в исходники SerialBus, понял, что времени потребуется прилично :((
Коллеги, может, я чего не догоняю и хочу странного?

Сейчас kuzulis придет и расскажет, что он там думал. :)
По мне, так в таких случаях, нужно протоколы и транспорты разделять.

Я им то-же самое талдычил, что проще передавать мастеру/слейву на вход любое QIODevice как транспорт, а у самого мастера/слейва создать некие проперти, типа типа протокола: Ascii, Rtu, Tcp. И тогда в зависимости от этих пропертей мастер будет в транспорт генерить соответствующие пакеты... как-то так.. примерно..

Но у них был ответ "вас это не касается" "мы делаем все по спецификации Modbus"... а я им грил, шо мир АСУТП гораздо ширше, чем они видят из своего окошка.. ну, в общем, такие дела... слово-за слово и.. понеслось.. сказал - шо больше не добавляйте меня в ревьюверы вашего Modbus кода. :)

Они еще сначала ходели libmodbus прикрутить, уже начали реализацию... а я им грю - хренью вы занимаетесь - хотите скрестить ежа и ужа... проще сделать самим с нуля (благо, модбас спека простая) и достаточно быстро...  но они потом все-таки выкинули libmodbus..


Эммм, а это не ко мне... я только в этом модуле помог добавить (добавил) реализации PeakCAN, TinyCAN.. А все претензии к Алексу Блашу и Ко (theqtcompany) - это их детище... :).
Так шо, многоуважаемый Old, - мимо! ;)

Именно так и нужно было.

Вы и так сделали большое дело! :)
Я ознакомился с исходниками, можно сделать еще один класс, QModbusRtuTcpMaster или, скорее, QModbusRtuClient. Но опыта нет - как его добавить в библиотеку?
Пробовал добавить в проект еще 3 модуля QModbusRtuClient.cpp, QModbusRtuClient.h и QModbusRtuClient_p.h. Все хорошо собирается, но при линковке со своей программой получаю неразрешенные ссылки. Ткните носом, пожалуйста, коллеги, как это делается?

UPD. И законно ли это?