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" <[email protected]>: > 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
