Hi, folks,
I would like to discuss new idea of transition of QtSerialPort to
an architecture with the plug-ins/backends.
The reason is that we can use different approaches on different
platforms to enumerating a list of available devices, and to
implementing a code of I/O engine.
It will simplify a code and its maintenance for developers,
and also will provide flexibility for users.
= QSerialPortInfo =
For example QSerialPortInfo::availablePorts() can be made with,
different ways, which I suggest to divide into plug-ins/backends:
* on Windows : [setupapi], wmi, generic
* on WinCE : [devmgr]
* on Linux : [udev], sysfs, generic
* on OSX : [iokit], generic
* on FreeBSD : [sysctl], generic
* on QNX : [generic?]
* other Unix : [generic]
where [...] means that this plugin is preferred/default for this platform.
The user can use/change desired plugin, e.g. via the
QT_SERIALPORTINFO_PLUGIN environment, or via command line e.g.:
{code}
set QT_SERIALPORTINFO_PLUGIN=wmi // on windows
myapp.exe
{code}
{code}
export QT_SERIALPORTINFO_PLUGIN=sysfs // on linux
myapp
{code}
{code}
myapp -qspi sysfs // on linux
{code}
and so on, similar to the Qt's platform backends, like this:
* http://doc.qt.io/qt-5/embedded-linux.html
Currently we have mess-up (mixing-up) multiple approaches in one
implementation file, via ifdefs and so on, that is looks funny/hard, e.g,:
* on Windows : setupapi + generic
* on Unix : udev + sysfs + generic
= QSerialPort =
Here also can be divided to the plugins/backends. E.g. some vendors
provides own HW chips which is RS232/485/TTL on the physical layer,
but has own vendor-specific API. An example it is FTDI chip with the
D2XX API, that is non-standard "serial port" API.
In this case the user can choose desired plugins via other
QT_SERIALPOR_PLUGIN environment, or via other command line, e.g.:
{code}
set QT_SERIALPORTINFO_PLUGIN=ftdi
set QT_SERIALPOR_PLUGIN=ftdi
myapp.exe
{code}
{code}
myapp.exe -qspi ftdi -qsp ftdi
{code}
Currently, I don't like the current implementation of internal architecture
of QtSserialPort where the code contains mix from different approaches
and so on, that is hard and ugly, IMHO.
So, dear community/developers/gurus, what do you think about? :)
BR,
Denis
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
