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

[kuzulis]

Ты не понял. Я предлагаю заменить на: SerialDevice::setDeviceId()

1. Но ведь \\\\.\\COMx (/dev/ttyS0) это ну никак не DeviceId, это скорее DevicePath
2. Пользователь может и не знать, что для портов с номерами >9 нужно писать \\\\.\\

Предлагаю для SerialDevice :

Может тогда на devicePath() (или pathToDevice())?

Но, если заменим и в SerialDevice, то нужно будет в SerialDevice изменить метод setDeviceName() на setName(),
а deviceName() на name() ?

И имена в setName() писать "короткие" просто : COMx (или ttyXYZ).
Или же не заменять имена методов (оставить setDeviceName()/deviceName()), а просто параметризировать их короткими именами/параметрами.

А вот для SerialDeviceInfo :
Оставить методы/параметры типа deviceName(), но в них указывать короткие имена.
А вот для получения "длинных" имен ( \\\\.\\COMx (/dev/ttyS0)), можно использовать devicePath() (вместо deviceId()).

А то что ты называешь "дружественным именем" - это не COMx (ttyXYZ),
а к примеру это:
Prolific USB-to-Serial Comm Port (COM4)
или
ZTE Proprietary USB Modem
или
ZTE Diagnostics Interface (COM9)
или
SAMSUNG CDMA Modem #2
и т.д. т.е. этот метод чисто для информации об устройстве (как и все остальные кроме deviceName()/setDeviceName()).

[b-s-a]

Ты не понял. Я предлагаю заменить на: SerialDevice::setDeviceId()

1. Но ведь \\\\.\\COMx (/dev/ttyS0) это ну никак не DeviceId, это скорее DevicePath
2. Пользователь может и не знать, что для портов с номерами >9 нужно писать \\\\.\\

Хорошо. Давай это назовем portId. Я против названия devicePath (и вообще упоминаний path).

Предлагаю для SerialDevice :

Может тогда на devicePath() (или pathToDevice())?

Но, если заменим и в SerialDevice, то нужно будет в SerialDevice изменить метод setDeviceName() на setName(),
а deviceName() на name() ?

И имена в setName() писать "короткие" просто : COMx (или ttyXYZ).
Или же не заменять имена методов (оставить setDeviceName()/deviceName()), а просто параметризировать их короткими именами/параметрами.

Вообще-то я предполагал, что порт можно открыть передав в качестве параметра или короткое имя порта (COM1), или его идентификатор (\\\\.\\COM1).

А вот для SerialDeviceInfo :
Оставить методы/параметры типа deviceName(), но в них указывать короткие имена.
А вот для получения "длинных" имен ( \\\\.\\COMx (/dev/ttyS0)), можно использовать devicePath() (вместо deviceId()).

А то что ты называешь "дружественным именем" - это не COMx (ttyXYZ),
а к примеру это:
Prolific USB-to-Serial Comm Port (COM4)
или
ZTE Proprietary USB Modem
или
ZTE Diagnostics Interface (COM9)

и т.д. т.е. этот метод чисто для информации об устройстве (как и все остальные кроме deviceName()/setDeviceName()).

Ох... Я и не знал. Значит это вообще нужно или убрать, или назвать как-то иначе. Как-нибудь, deviceDescription().

[kuzulis]

Хорошо. Давай это назовем portId. Я против названия devicePath (и вообще упоминаний path).

Я б вообще не использовал этот метод.

Вообще-то я предполагал, что порт можно открыть передав в качестве параметра или короткое имя порта (COM1), или его идентификатор (\\\\.\\COM1).

А я предполагал, что нужно открывать ограничившись только короткими именами: COMx, ttyXYZ.
т.е. запретить любое двоякое толкование.

Ох... Я и не знал. Значит это вообще нужно или убрать, или назвать как-то иначе. Как-нибудь, deviceDescription().

Не, ну ты хоть бы запустил/проверил/ознакомился для приличия примеры QSerialDevice в /gui/testapp , а потом бы мы конструктивно пообщались. Или слазил бы в виндовый реестр.
А то диалог напоминает: я тебе про Фому, ты мне про Ерёму.

[b-s-a]

Ох... Я и не знал. Значит это вообще нужно или убрать, или назвать как-то иначе. Как-нибудь, deviceDescription().

Не, ну ты хоть бы запустил/проверил/ознакомился для приличия примеры QSerialDevice в /gui/testapp , а потом бы мы конструктивно пообщались. Или слазил бы в виндовый реестр.
А то диалог напоминает: я тебе про Фому, ты мне про Ерёму.

Я виндой не пользуюсь.
Под Linux у меня testapp для стандартного порта ничего толком не показала, а friendlyName() был " (/dev/ttyS0)". А так же было еще 30 портов, которых фактически в системе нет (но записи в /dev/ есть).

и так. Что я предлагаю:
SerialDeviceInfo::name() -> "COM1", "ttyS0"...
SerialDeviceInfo::deviceId() -> "\\\\\\\\.\\\\COM1", "/dev/ttyS0"...
SerialDeviceInfo::friendlyName() -> тут логика сложней. Но вариант " (/dev/ttyS0)" не допустим. В крайнем случае должно возвращать тоже, что и name().

Так же предлагаю сделать возможность простого определения существует порт или только в системе зарегистрирован. Для этого достаточно его открыть и попытаться получить характерные для порта параметры.

Библиотеку libudev.so следует грузить динамически. Если ее нет, то откатываться к стандартному минимальному варианту.

[lit-uriy]

Как вариант:
portName = "COM24", "ttyS45"
fileName = "\\\\\\\\.\\\\COM24", "/dev/ttyS45"
deviceName = "FTDI serial USB converter", "Prolific USB-to-Serial Comm Port (COM4)"

[kuzulis]

Под Linux у меня testapp для стандартного порта ничего толком не показала, а friendlyName() был " (/dev/ttyS0)".

Да, потому что в линухе для стандартных портов нет описания. Тут можно самим возвращать что-то типа "Стандартный порт".
И да, так и быть, можно отказаться от метода friendlyName() и вместо него оставить метод description() который будет возвращать описание.

и так. Что я предлагаю:
SerialDeviceInfo::name() -> "COM1", "ttyS0"...

Ок, тогда и в SerialDevice тоже меняем имя метода setDeviceName(const QString &deviceName) на setName(const QString &name)!
Где name - это будут только имена типа "COM1", "ttyS0".
(аналогично меняем и имена геттеров в SerialDevice ).

SerialDeviceInfo::deviceId() -> "\\\\\\\\.\\\\COM1", "/dev/ttyS0"...

Не знаю, не нравится мне ID.
Я бы заменил на что нить другое, например на: alias() или path().

т.е. в итоге:

SerialDevice

Код

C++ (Qt)
class QSERIALDEVICE_EXPORT SerialDevice : public QIODevice
{
...
...
    explicit SerialDevice(QObject *parent = 0);
    explicit SerialDevice(const QString &name, QObject *parent = 0);
    virtual ~SerialDevice();
 
    void setName(const QString &name);
    QString name() const;
...
}
 

где
   name = "COM24", "ttyS45"

SerialDeviceInfo

Код

C++ (Qt)
class SerialDevice;
class SerialDeviceInfoPrivate;
 
class SerialDeviceInfo
{
public:
   SerialDeviceInfo(); //produces NULL info
   SerialDeviceInfo(const SerialDeviceInfo &other); //copy constructor
   explicit SerialDeviceInfo(const SerialDevice &device);
   SerialDeviceInfo& operator=(const SerialDeviceInfo &other);
   void swap(SerialDeviceInfo &other);
 
   QString name() const;  //COM1, ttyS0...
   QString alias() const; //"\\\\\\\\.\\\\COM24", "/dev/ttyS45"
   QString description() const; //"Последовательный порт", "Prolific USB-to-Serial Comm Port", "Motorola Phone (E1 iTunes)"
   QString manufacturer() const; //"(Стандартные порты)", "Prolific Technology Inc." 
 
   bool isNull() const;
   bool isBusy() const;
   QList<int> standardBauds() const;
   static QList<SerialDeviceInfo> availableDevices();
private:
    Q_DECLARE_PRIVATE(SerialDeviceInfo)
    SerialDeviceInfoPrivate *d_ptr;
};
 

Так же предлагаю сделать возможность простого определения существует порт или только в системе зарегистрирован. Для этого достаточно его открыть и попытаться получить характерные для порта параметры.

Согласен, определять нужно. Но вот, может можно обойтись не открывая порт?
Может быть, есть и еще какие-нить возмоджности?

Библиотеку libudev.so следует грузить динамически. Если ее нет, то откатываться к стандартному минимальному варианту.

Согласен. Типо парсить вручную /proc, /sys  

Как вариант:
portName = "COM24", "ttyS45"
fileName = "\\\\\\\\.\\\\COM24", "/dev/ttyS45"
deviceName = "FTDI serial USB converter", "Prolific USB-to-Serial Comm Port (COM4)"

А то что я чуть выше предложил не пойдет?

[lit-uriy]

alias() мне не нравится, т.к. речь всё равно не о псевдониме идёт, а о полном имени файла (не пути).
лучше fileName().
Насчёт description() - вполне.

>>Для этого достаточно его открыть и попытаться получить характерные для порта параметры.
И до какого номера/имени проверять? И в какой момент? А если порт занят?

В программе COM PortToolkit показывается список доступных портов, и занятые помечаются. Как это делается я не знаю.

[lit-uriy]

Что-то тут может и полезное:
http://www.naughter.com/enumser.html

[kuzulis]

alias() мне не нравится, т.к. речь всё равно не о псевдониме идёт, а о полном имени файла (не пути).
лучше fileName().

Может тогда : fullName() ?

[b-s-a]

Согласен. Типо парсить вручную /proc, /sys

Нет! Просто тупо распарсить содержимое /dev по имени файла.

Может тогда : fullName() ?

А может просто - device()? А у SerialDevice метод сделать setDevice().
Я просто не хочу, чтобы эта хрень имела в названии слово name. Так как народ будет пытаться его выводить пользователям. И вот будет сюрприз, когда однажды выведется хрен знает что (типа UUID).

[kuzulis]

А может просто - device()? А у SerialDevice метод сделать setDevice().
Я просто не хочу, чтобы эта хрень имела в названии слово name. Так как народ будет пытаться его выводить пользователям. И вот будет сюрприз, когда однажды выведется хрен знает что (типа UUID).

А может setDeviceName(const QString &deviceName)/deviceName() ,
при этом, параметрами будут имена: "COM1", "ttyS0".
И жестко ограничится только такими именами!
Т.к. имена  "COM1", "ttyS0" и есть имена устройств, если судить здраво.

т.е. SerialDevice
будет содержать (как и ранее было) методы:  setDeviceName(const QString &deviceName)/deviceName(),
где имена: "COM1", "ttyS0".


т.е. SerialDeviceInfo
будет содержать  device() и будет возвращать: "\\\\\\\\.\\\\COM1", "/dev/ttyS0"...
т.к. это не только имя устройства, а еще и путь к устройству!
и будет содержать deviceName(), где имена: "COM1", "ttyS0".

Я склоняюсь к такому варианту.

[b-s-a]

Я бы хотел, чтобы SerialDevice::setDeviceName() принимал как "\\\\\\\\.\\\\COM10", так и "COM10", и это было бы равнозначно. Чтобы понять почему, нужно представить, что файл устройства создан не там, где мы его ожидаем увидеть (ну мало ли). А так, мы убиваем сразу всех зайцев.
В то же время, чтобы SerialDeviceInfo::device() возвращала результат только вида "\\\\\\\\.\\\\COM10"...

Еще можно добавить в SerialDevice конструктор и метод установки устройства из объекта SerialDeviceInfo. Что сильно упростит жизнь.

[kuzulis]

Я бы хотел, чтобы SerialDevice::setDeviceName() принимал как "\\\\\\\\.\\\\COM10", так и "COM10", и это было бы равнозначно. Чтобы понять почему, нужно представить, что файл устройства создан не там, где мы его ожидаем увидеть (ну мало ли). А так, мы убиваем сразу всех зайцев.

Ну зачем так усложнять то?

Можно сделать проще:

SerialDevice::setDeviceName() - только COM1, ttyS0
SerialDevice::setDevice() - только "\\\\\\\\.\\\\COM10", "/dev/ttyS0"

SerialDeviceInfo::deviceName() - только COM1, ttyS0
SerialDeviceInfo::setDevice() - только "\\\\\\\\.\\\\COM10", "/dev/ttyS0"

Каждый метод должен заниматься своим делом!

Разделяй и властвуй (с)

ЗЫ: хотя,

принимал как "\\\\\\\\.\\\\COM10", так и "COM10", и это было бы равнозначно.

Фигня какая то... А что тогда будет возвращать SerialDevice::deviceName() ?
Если устанавилваем "\\\\\\\\.\\\\COM10", то возвращает "\\\\\\\\.\\\\COM10", если "COM10", то "COM10" ?
Ерунда какая то.

Лучше сделать только "COM10", "ttyS0" и не интерпретировать как вздумается, ИМХО.

Еще можно добавить в SerialDevice конструктор и метод установки устройства из объекта SerialDeviceInfo. Что сильно упростит жизнь.

Согласен.

[lit-uriy]

>>А может просто - device()?
device - устройство, а не имя файла, порта.

>>Я просто не хочу, чтобы эта хрень имела в названии слово name.
>>Так как народ будет пытаться его выводить пользователям.
если есть чёткое отличие в именах, например:
port->name()
port->fileName()
то уже становится очевидно

[lit-uriy]

>>Т.к. имена  "COM1", "ttyS0" и есть имена устройств, если судить здраво.
всё таки "COM1", "ttyS0" - имена портов, а не устройств.
Устройства - мобильник, промконтроллер, преобразователь интерфейса, и "стандартный последовательный порт в конце концов"