On Tue, Mar 12, 2013 at 1:07 AM, Alex Henrie <[email protected]> wrote:
> 1. Put #ifdef around the function prototype so that handle() returns > an int on Unix and a HANDLE (a.k.a. void*) on Windows. In the > documentation, do not specify handle()'s return type. > As written, this does not sound a good idea to me because of the following two concerns: 1) It is inconsistent with the rest. 2) The public documentation and interface should be in line. > 2. Define a new type analogous to WId and Q_PID for serial port > handles. Use #ifdef to make this type equivalent to int on Unix and > HANDLE or void* on Windows. Make handle() return this type. > > QSerialPort's primary maintainer, Laszlo Papp, is in favor of option > #2, but says that it has to wait until a typedef Qt::Device/IoHandle > is added to QtCore. He says that this Qt::Device/IoHandle is going to > be for serial ports, parallel ports, bluetooth, and USB. > Hmm, that is a bit of misinterpretation. 1) I am not the "primary maintainer". 2) I did not try to say, it has to be added to QtCore. All I said, it needs some more time to investigate about the proper API and considering that this feature has not been added to QExtSerialPort and so forth for more than eight years, I think it is not the most important thing to get done now for the release. The feature freeze was announced for the middle March, and I have concerns that I cannot finish the investigation I wished to do for this (i.e. even just for being able to review properly). Hence, I was trying to suggest to postpone the feature to 5.2. The idea is that, I personally do not wish to have an API added in a rush. We still have a room for the existing features to get up to the quality before adding further ones for this release. Laszlo
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
