qserialport теперь под лицензией LGPL

Примечательно, что в Qt нет штатных средств для работы с последовательным портом.

Перечитал два раза, но понять почему Qt должен уметь работать с последовательным портом - я не смог 8)

qt - это не только тулкит.

хотя да, как-то я и забыл, что там есть «обертки» для потоков, сетевая составляющая и много всяких вкусностей... но последовательный порт - не слишком ли уж низкоуровневая задача? )

даже в питоне есть pyserial )
и задача очень даже ибо куча промышленного оборудования очень любит RS232/485

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

банально с прибора содрать старые настроечные коэффициенты и записать новые - и все любят делать это с мышкой на ноуте.
или твой пульт на ARM увязывает между собой надцать датчиков, висящих все на том же последовательном порту.
в общем, мне даже лень расписывать на сколько это вещь нужная )

и чем оно лучше qextserialport?

Давайте теперь про каждый вышедший класс для куте в новости писать. И про каждый новый виджет.

а я как-то сам набацал классы на с++ без кутей для работы с сериал портом, и нормально.

давайте теперь помимо этого еще про каждую «ненужность» объявленную ХИГом новости писать.

Новость: «В Qt появилость x» Новость: «В Gtk объявлено не нужным y и выпилено из исходников»

я сразу решил что qextserialport под GPL - когда то об этом здесь писали. правда потом выяснилось что он BSD License, но новость тереть уже жаль

Ну Qt предназначена не только для графических приложений, а для любых приложений, которые должны быть кроссплатформенными на уровне В проприетарной версии даже есть редакция, где не входит QtGui.

Маразм и подсаживание на иглу.
Уже и бит в ОЗУ не могут записать без Qt ))
Потом еще удивляются почему у них приложения рамером в чемодан.

Абсолютно согласен // кутененавистник :)

Пример такого кода, работающий одинаково на всех популярных платформах, в студию.

> Примечательно, что в Qt нет штатных средств для работы с последовательным портом.

как и в жабе, кстати.

кстати, очень настораживает название класса (QSerialPort): в куте идентификаторы вида /^Q_\w*/, /^Q[A-Z]\w*/, /^Q3[A-Z]\w*/, /^q[A-Z]\w*/ и qobject_cast зарезервированы за тулкитом (по памяти, могу ошибаться). т.е. если вы используете Qt4, то должны соблюдать эти правила, иначе совместимость с будущими версиями не гарантируется. (QextSerialPort под ограничения не попадает.)

А чем им /dev/ttyS0 не угодил?

в венде его нет :-)

эти манящие сигнал-слоты ))

да запросто , tcl :


switch $tcl_platform(os) {
{Linux} {set comPort /dev/modem}
{SunOS} {set comPort /dev/cua/a}
{Windows NT} {set comPort COM2:}
# ....
default {error «Must configure comPort»}
}


set fh [open $comPort RDWR]
fconfigure $fh -blocking 0 -buffering none \
-mode 9600,n,8,1 -translation binary -eofchar {}

-----------------------

нет дурней изучать дурную бесконечность ))

ты б еще код с pyserial привел ))
к слову в qextserialport схема такая же - главное отдать в коде правильное имя компорта

1) Для Qt родной язык всё же C++ (в стандартной библиотеке которого нет возможности работы с последовательными портами) , плюс в неродных тоже не обязательно во всех есть. А ты предлагаешь переходить на язык более высокого уровня, который не всегда подходит для тех задач, для которых используется C++.
2) А чем интерпретатор tcl в данном плане («Потом еще удивляются почему у них приложения рамером в чемодан») лучше Qt?

Зря хихикаешь, есть и нормальный api из С к этому, и это пережило и еще переживет многие высеры.
А только tcl 300 ... 400 кB весит в бинарях.
Но но , мода ... нонче другая:
слепить горбатого, обьявить логичным его, и клеить к нему костыли в ассортименте с красивыми названиями.

Даже Python куда легче Qt.

Вот завязались мы на Qt на работе, теперь думаю, как бы отвязаться. А всё потому, что не решился предложить перейти на Python. Молодой был, глупый. Эх...

> А чем интерпретатор tcl в данном плане («Потом еще удивляются почему у них приложения рамером в чемодан») лучше Qt?

Как для меня , код написан один раз - работает всегда и везде,
Хотя это обещают и не делают другие, а в tcl тихо молчат в тряпочку и все работает.

>Даже Python куда легче Qt.

В каком месте? По производительности быстрее? По размеру интерпретатора и runtime-библиотек? Если и есть разница в размере, то некритична, разницу в несколько мегабайт вряд ли сейчас кто заметит.

мне после питона кьют шел туго-туго. эти выносящие мозг ссылки и указатели стоит терпеть только из за высокого быстродействия ))

прежде всего , Python нестабилен для таких вещей.
на этом можно базар и закрывать.

>кьют шел туго-туго. эти выносящие мозг ссылки и указатели стоит терпеть только из за высокого быстродействия ))

Ссылки и указатели — вообще-то элементы языка C++, а не набора библиотек Qt. — К. О.

Ну вот, один предлагает Python, другой — tcl, третий ещё что-нибудь. А если кто-то считает более целесообразным написать какую-либо конкретную программу именно на C++? Почему он не имеет право так считать?

«Мы говорим Ленин, подразумеваем - партия, мы говорим партия, подразумеваем - Ленин» (с)

Ха ха, я тоже лет десять назад страдал этим.
Потом приперли сроки, послал нахрен вантуз,
успел таки обнаружить tcl в linux и решил задачу за два дня (и для вантуза в том числе)
И код арбайтен и по сей день.
А за это время что-то там усохло , отвлилось, обьявили навозом, начали трахать мозг MVC , ... да гори все оно синим пламенем.
Быстрее чем биты станут в UART ничего не будет и все зависит от буферизации.

Ну указатели и ссылки — это изобретения создателей языков C и C++, а не троллей. А тролли используют их в Qt, т.к. как в C++ по другому передать в функцию не копию объекта, а оригинал?

эти изоборетения нужны постольку поскольку плюсы близки к железу во имя высокого быстродействия.
а в том же питоне все что не сделано все для людей - ссылки органичны изначально )

меня лично кьют прельстил изобилием платформ в первую очередь, сотнями возможностей во вторую )
например то, что там из коробки есть всякие кинетик и прочие мейнстримные плюшки меня покорило вмомент

Для работы с последовательным портом надо использовать boost::asio.

радуют такие выставки! особенно даты их проведения тем более если ты живёшь за пределами нерезиновой и работаешь 5\2 ушлёпки

изюминка в том, что сабж умеет сигнал-слот и органично вписывается в идеологию кьюта

> Даже Python куда легче Qt.
Язык легче библиотеки. Brutal facepalm.

Почитай уже вот это наконец: http://www.riverbankcomputing.com/static/Docs/PyQt4/pyqt4ref.html

>изюминка в том, что сабж умеет сигнал-слот и органично вписывается в идеологию кьюта

А без сигналов и слотов он умеет?

Отличная новость, ибо реально надо. А qextserialport не айс...

А без сигналов и слотов можно использовать любую другую библиотеку или вообще без неё.

В каком месте? По производительности быстрее? По размеру интерпретатора и runtime-библиотек?

В обоим местах в большинстве случаев.

И? Ты сначала попиши на этом PyQt, а потом выпендривайся. И да, Python - не только язык, но и библиотека к нему. Внезапно, да? Поэтому и советуют сначала узнать, а потом говорить.

Писал и немало, так что мимо.

> Ну указатели и ссылки — это изобретения создателей языков C и C++, а не троллей. А тролли используют их в Qt, т.к. как в C++ по другому передать в функцию не копию объекта, а оригинал?

Есть на самом деле способы, использующие простую статическую обёртку над динамическим объектом. Описаны у Коплиена. Помимо прочего позволяют в 99% процентах случаев забыть про конструкторы и деструкторы и использовать указатели только когда надо действительно на что то указывать.

Готоваяь реализация такого счастья, кстати, имеется. В Ultimate++, этакий конкурент Qt, тоже GUI-фреймвок, пытающийся заменить собой все остольные C++ либы. Правда последовательного порта туда вроде никто ещё не написал. И не такой он гламурный, как Qt. Зато U++ — достаточно компактный и весьма шустро компилится, производя при этом весьма шутрые программы. С удобным синтаксисом и без moc-. Есть и своя, заточенная под U++ IDE, правда она немножечко для инопланетян, но привыкнуть можно.

И что? Теперь ты можешь объяснить, к чему твой комментарий? Или это так, к слову?

Кстати, PyQt наконец-то научился делать incref для виджетов? Или всё ещё падает, если ссылку на виджет специально не сохранить где-нибудь в питоновском коде?

Это то, про что в журнале OpenSource несколько выпусков писали? И как оно, пробовали?

Оно родимое. Судя по первым эксперминетам — весьма хорошая библиотека, грабли под ноги пока не попадали. Компилится (и само, и приложения под него) по сравнению с Qt — просто со скорстью света. Общий уклон в статику, даже .lay файлы с визуальной раскладкой виджетов, это на самом деле такой корректный C++ код (с учётом добавленых б-кой макросов) который тоже (как правило) компилируется статически.

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

Я сейчас от C++ несколько отошёл, но когда пощупал Ultimate++ сразу захотелось использовать его по крайней мере «для дома для семьи».

TheIDE конечно штука странноватая, но привыкнуть можно. Судя по тому, что ни у кого так и не дошли руки написать улучшенный вариант этой среды — все привыкают.

Спасибо, поизучаю.