> why are you conflating backends and plugins?
I don't know why I do it.. ;)
> if you feel you need to refactor the code to achieve better structural
clarity, i'm all
for it - but don't over-engineer it just because you can.
yes, I need in "to refactor the code to achieve better structural clari
On Sat, Feb 13, 2016 at 02:24:38PM +0300, Denis Shienkov wrote:
> I would like to discuss new idea of transition of QtSerialPort to
> an architecture with the plug-ins/backends.
>
why are you conflating backends and plugins? i see no apparent need to
make the backends dynamically switchable, i.e.,
> 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 plugi
> -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,
Chris,
> Indeed it would be nice to have an extended API for controlling
vendor specific extension in a uniform way. Switching between
RS232/422/485 is a pretty common feature (including switching b/w
full/half duplex, (des)activating termination resistor), as is
controlling a few extra GPIO.
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 simpli
