[Development] Proposal - QtSerialPort graduation from the Playground

Denis Shienkov scapig2 at yandex.ru
Sat Jan 12 13:13:28 CET 2013


Hi Uwe,

First, QtSerialPort closely linked to the Qt event-loop subsystem with using fully async signal/slots concept.
This allows you to not use a separate thread to monitor I/O events.

> By the way: what are the major differences between QtSerialPort and the
> qextserialport project ?

IMHO, this for QtSerialPort:
~~~~~~~~~~~~~~~~~~~~~~~~~

class SerialPort:

+ Support fully asynchronous I/O with event-loop
+ Support fully synchronous I/O without event-loop (waitForXXX methods)
+ Support by default data buffering like QAbstractSocket
+ Support WinCE
+ Support any custom baud rate
+ Support I/O errors detection (framing, parity..)
+ Support policies for stream processing
+ Support extended line controls (like getting RTS/DTR on Windows, set/send break conditions and so forth)
+ Support different stream directions (exclude Windows)
+ Support any parities types (include Mark/Space)

- Using only binary mode stream
- Using only exclusive mode
- Using zeroes timeouts (i.e. not using it, because async stream)
- No monitoring/notifications about Line signals changed (like DSR, CTS and so forth, because on *nix it is not supported) 

class SerialPortInfo

+ Support a large number of ports manufacturers, both virtual and hardware.
+ On Gnu/Linux for enumerating can be using Udev, or can be disabled

- No monitoring/notifications for plugged/unplugged ports (More precisely, the support was before - but it was abandoned.)


Although, I would not call it a disadvantage - it's just such a features. :)


IMHO, this for QextSerialPort:
~~~~~~~~~~~~~~~~~~~~~~~~~

IMHO, do not see any features.


In summary I would say that QtSerialPort completely outperforms conventional counterparts of similar libraries for Qt, and it's true.
You yourself can compare it. :)


Best regards,
Denis


12.01.2013, 14:33, "Uwe Rathmann" <Uwe.Rathmann at tigertal.de>:
> On Sat, 12 Jan 2013 11:22:31 +0400, Denis Shienkov wrote:
>
>>> A cross platform compatible API for the serial port is a useful thing,
>>> but is there a good reason for limiting it to Qt applications ?
>>  Why do you think that this is a limitation?
>
> Well, an application using wxWidgets probably wouldn't use a library that
> requires Qt - even if it needs a cross platform API for the serial port.
>
>>  This is just a separate, cross-platform implementation of the serial
>>  port, taking into account the Qt-specific,
>>  and designed specifically for Qt, like as QAbstractSocket, QFile and so
>>  forth...
>
> In general I see 2 reasons why a lib should be using Qt:
>
> 1) The implementation has a significant benefit from using Qt
> 2) The API needs to use Qt classes to be "usable in a comfortable way" in
> a Qt application
>
> Hiding the platform specific details below a common API is the flesh of a
> cross platform serial port lib - and IMO I don't see where Qt is of any
> help for this.
>
> The question then is how much substance is left for a Qt API on top
> ( QIODevice, signals/slots .. ). In case of the version of qextserialport
> I had seen it was a couple of lines only, that could have been documented
> and done in application code instead.
>
> By the way: what are the major differences between QtSerialPort and the
> qextserialport project ?
>
> Uwe
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



More information about the Development mailing list