[Development] [Proposal] Future QtSerialPort with plugins architecture

Denis Shienkov denis.shienkov at gmail.com
Mon Feb 15 10:03:47 CET 2016


> 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.blasche at theqtcompany.com>:

>
>
>
> > -----Original Message-----
> > From: Denis Shienkov [mailto:denis.shienkov at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160215/182c8f48/attachment.html>


More information about the Development mailing list