Re: [Development] What do you know about Qt::Device/IoHandle?
2013/3/12 Sergey Belyashov sergey.belyas...@gmail.com: Laszlo is not primary maintainer. But Denis is. Laszlo is most active developer. Our policy is to accept features if only all 3 maintainers accepts it. I an Denis can accept your change. If you persuade Laszlo to accept patch then it will be merged. Thanks for clearing that up for me. 2013/3/11 Laszlo Papp lp...@kde.org: 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. QextSerialPort does not need handle() so badly because QextSerialPort does not force exclusive mode (TIOCEXCL) like QSerialPort does. 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. The best feature the API could have is the ability to add any feature you want by accessing the file descriptor. What about making the typedef QSerialPort::Handle private? If it was private, handle() could return a QSerialPort::Handle in Qt 5.1 and then you could change handle() to return whatever you want in Qt 5.2 without breaking source or binary compatibility. No one could complain. If you still disagree, what other option are you trying to investigate? Thiago made it pretty clear that you can't have a one-size-fits-all typedef for serial port, parallel port, bluetooth, and USB handles. By the way, though I'd love to see handle() in Qt 5.1, if you agree on a patch that fixes this problem and promise to commit it in Qt 5.2 I would be satisfied. -Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] What do you know about Qt::Device/IoHandle?
On segunda-feira, 11 de março de 2013 19.07.53, Alex Henrie wrote: It seems to me that Qt::Device/IoHandle could only work as long as Qt is not ported to any operating system that uses different data types for serial port, parallel port, bluetooth, and USB handles. However, Laszlo says that at least one QtCore developer supports this approach anyway. Did he also mention that the QtCore maintainer thinks that using one type for all of those is a bad idea? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] What do you know about Qt::Device/IoHandle?
On Tue, Mar 12, 2013 at 1:07 AM, Alex Henrie alexhenri...@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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
