[Development] What do you know about Qt::Device/IoHandle?

[Laszlo Papp]

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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130312/92150584/attachment.html>