Создаю библиотеку для работы с последовательными портами. [УШЕЛ ИЗ ПРОЕКТА].

[b-s-a]

думаю, писать про стандартные фишки смысла нет. Только про особенности.

3. Нужно ли как-то где-то указать, что QtSerialPort разрабатывается предназначен для Qt5?

На мой взгляд, надо его еще позиционировать и для Qt 4.8. Так как Qt 5 еще даже в бранч не выделен.

[kuzulis]

Ну, вроде дописал Вики.
Осталось что придумать написать в "Новости" и "Возможные проблемы"

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

В общем, подправьте кто нить.

Вопрос: Кто возьмется перевести эту Вики страничку на английский после её ревизии и утверждения?

[kuzulis]

Я через гугл транслит накалякал английскую ВиКи. Просьба - подредактировать.

http://qt-project.org/wiki/QtSerialPort

[b-s-a]

заменил "инструментарий" на "библиотеку" в кратком описании.
Я вот думаю, может добавить краткое описание интерфейса класса, а так же какой-нибудь простейший пример использования.
Кстати, ты лицензионные соглашения в хидеры уже напихал? Может все-таки какую-нибудь BSD или MIT использовать, для повышения популярности?

[kuzulis]

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

А зачем? Для этого документация имеется с примерами и т.п.

Можно просто сгенерить html документацию, разместиьт ее на qt-project.org (правда, хз, можно ли это), а потом в ВиКи вставить ссылки на документацию.

Кстати, ты лицензионные соглашения в хидеры уже напихал?

нет еще.

Может все-таки какую-нибудь BSD или MIT использовать, для повышения популярности?

Врядли. Мариус говорил что лицензия будет такая-же как и для Qt.

[b-s-a]

Никто не мешает BSD сменить на LGPL. А вот обратно уже нельзя.

[kuzulis]

Может быть, все-таки, в SerialPortInfo добавить поддержку VID/PID ?
т.к. это тоже важная информация!

Некоторым пользователям необходимы эти ID-ы в разработке приложений.
Меня уже часто спрашивают: "А на# я убрал это из библиотеки?"

А я и сам не знаю зачем (повелся), ИМХО, они не мешали.

 

[b-s-a]

Ты для всех платформ их сможешь поддержать?

[kuzulis]

Для Win NTx, Gnu/Lin (с использованием libudev), MacOSX - вполне реально.

Для всех иных (включая Symbian, FreeBSD, WinCE) даже description, manufacturer невозможно определить,
но description и manufacturer присутствуют в классе.

Хотя, для FreeBSD, начиная с 9 (вроде) это можно сделать для USB/PCI устройств используя ядрёное АПИ (или типа того),
но связать информацию, полученную от АПИ с каким-то у-вом в /dev не получится.
Я уже спрашивал об этом на винграде и на девелоперском BSD-шном форуме

Так, что в любом случае, во всех ОС, отличных от трех самых распростаненных выйдет засада со всеми параметрами.

На крайняк, не поддерживаемые параметры просто будут возвращать "Unknown".

Кстати, а что лучше возвращать при невозможности получения того или иного параметра?
Пустую строку, "Unknown", "Undefined", "Not exist" , свой вариант...

[b-s-a]

0 для целых и QString() для строк

[kuzulis]

Ну так ты согласен насчет добавки VID/PID?

[b-s-a]

ну если народ так просит...
Кстати, а vid и pid 16-ти разрядные? Если да, то в качестве ошибки можно возвращать -1.

[kuzulis]

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

Пусть уж будут в виде строки, а если не найдена - то возвращать QString(), Ок?

ЗЫ: Там от тебя еще нужен code review насчет установки Custom Baud Rate. Я добавил решение из мержа на гиториусе,
но не знаю, корректно или нет упростил его. Нужет твой наметаный глаз.

[b-s-a]

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

Если они содержат числовые значения, то зачем оставлять в виде строк? Числа намного проще использовать потом.

[kuzulis]

1.

Если они содержат числовые значения, то зачем оставлять в виде строк? Числа намного проще использовать потом.

Дык все-равно придется преобразовывать из строки в число..
А если кому-то нужно в виде строки - то получится цепочка "строка-число-строка"
Зачем многократные преобразования? Кому надо - сам в число перегонит. ИМХО.

2.
Еще предложение: может быть, лучше отказаться от использования превиксов m_ для членов класса?
А то мозолят глаза

3.
И кстати, что ты написал про reference в Gerrit? Что ты имел ввиду?
Упс, понял - надо & подставить..

И почему заполнять хеш нужно именно в standardRatesMachTable()?
Упс, тоже понял...

И что означает твой комментарий "So please do not squash unrelated changes." ?