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
