[Development] What do you know about Qt::Device/IoHandle?
lpapp at kde.org
Tue Mar 12 05:04:53 CET 2013
On Tue, Mar 12, 2013 at 1:07 AM, Alex Henrie <alexhenrie24 at gmail.com> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development