On Sat, Jan 12, 2013 at 10:32 AM, Uwe Rathmann <[email protected]>wrote:
> 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 > As far as I can briefly tell: 1) API * It is based upon Qt by inheriting QIODevice (and hence following the Qt interface). * Relevant qint32/64 usage. * We also use QString for setting all the serial port info around throughout the SerialPortInfo class. * We also use the Qt containers to return lists for instance. * Signal/Slot usage 2) Implementation * We use Q_ENUMS, Q_DECLARE_FLAGS, Q_DECLARE_OPERATORS_FOR_FLAGS and so forth for the serial port related enumerations like baudrate, databits, parity, stop bits, flow control, and so forth. * We use windows specific Qt classes which would be more difficult without, like QWinEventNotifier. * We use other Qt classes like QRingBuffer. * QElapsedTimer all around. * QIODevice for QIODevice::ReadWrite and so forth. * QByteArray and QString internally to deal with raw data and strings. * Signal/Slot mechanism with connect, emit and so forth. * QThread for dealing with threads. * QMutex for dealing with sync'ing. * QHash for notifiers. * QVector for container purpose * QLatin1String for path prefix * Q_ASSERT for assertion purposes. * QSocketNotifier for socket management. * QStringList for string containment. * QVariant for the registry property. * QFile for dealing with files. By the way: what are the major differences between QtSerialPort and the > qextserialport project ? > It is a bit more than you ask, so pardon me, but I think it is worth reading if you care enough. :) https://groups.google.com/forum/#!topic/qextserialport/kLtfpovqVWk Laszlo
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
