> The system must support the concept of a default plugin for the current platform.
Yes, of course. For example, the name of a default plug-in will be defined in DEFINES in the *.pro file at a stage of compilation of the module. > Maybe you forgot to mention it in your mail but choosing the plugin via env or app parameter is not sufficient. It is used only for specifying of other plugin's name, that is other than default plugin. BR, Denis 2016-02-15 10:05 GMT+03:00 Blasche Alexander < alexander.blas...@theqtcompany.com>: > > > > > -----Original Message----- > > From: Denis Shienkov [mailto:denis.shien...@gmail.com] > > > I would like to discuss new idea of transition of QtSerialPort to > > an architecture with the plug-ins/backends. > > 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} > > In principle I have no problem. Maybe you forgot to mention it in your > mail but choosing the plugin via env or app parameter is not sufficient. > The system must support the concept of a default plugin for the current > platform. > > -- > Alex >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
