[Development] 5.7 new features and 5.6 changelog

[Knoll Lars]

Hi everybody,

It would be great if those of you who haven’t done so yet fill in the 5.7 new 
features page on the wiki (https://wiki.qt.io/New_Features_in_Qt_5.7), so that 
we can get a good overview over the bigger new features in 5.7.

In addition, I’d like to ask every maintainer to have a look at the 5.6 
changelog files, and checks that everything ok and the changelog is complete 
for your area.

Thanks,
Lars


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Made with Qt - Bluescape at TED 2016

[Romain Pokrzywka]

Hi all,

I just wanted to share this piece of news, as a serious piece of hardware
and UI is currently featured in the main lobby of the TED 2016 conference
in Vancouver, and it's all made with Qt!

https://www.bluescape.com/press/bluescape-introduces-visual-collaborative-workspace-to-1350-attendees-at-ted2016/

I've also attached a picture of the Bluescape Wall that was set up over
there (sorry for the poor quality, it had to be under 100kb). It's a 3x5
array of 55'' multitouch displays sporting a total resolution of 9600x3240
pixels, and running on a 3-GPU machine (one GPU per row). It's running Qt
5.5 and makes a big use of QtQuick2 and QtWebEngine. There's also two 84''
single-display units on each side.

Kudos to all contributors in the Qt community for making Qt such an awesome
development framework, and special thanks to the folks at The Qt Company
and KDAB.

Hopefully we'll have a chance to showcase it again at the Qt World Summit
in San Francisco this fall!

Cheers,
Romain
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] some questions about QtGamePad

[Matthew Woehlke]

On 2016-02-15 15:23, Matthew Woehlke wrote:
>> So I do not support expanding the scope of QtGamepad in the way you
>> propose, as I think if it belongs anywhere it is in a generic input API
>> (or you can always still just wrap SDL's input module pretty easily).
> 
> I might be more inclined to agree if there was already a QJoystick or
> some such. As is, I think, at best, you're putting the cart before the
> horse.

Let me put that differently. By artificially constraining QGamePad, you
are forcing people with needs that don't exactly conform to the
completely arbitrary limitations you have chosen to impose to *recreate
functionality that you are already using*. That's just... inconsiderate.

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] some questions about QtGamePad

[Matthew Woehlke]

On 2016-02-15 14:46, Nichols Andy wrote:
> QtGamepad is intentionally limited to gamepads, and does not include support 
> for joysticks, or generic devices with an arbitrary number of axes/buttons.

That's... stupid IMNSHO. Especially since...

> The design was primarily inspired by the HTML 5 gamepad API:
> https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API/Using_the_Gamepad_API

...I don't see anything here that restricts the HTML 5 interface to some
particular number of axes or buttons, or in any way really precludes it
from being used for devices that are not "gamepads" (i.e. traditional
joysticks). Nor do I see anything that tries to impose specific
semantics on what buttons are available or have what indices.

> Gamepads have roughly the same Button/Axes configurations

*Modern* gamepads may happen to have similar button/axis configurations,
but this is incidental. There is no guarantee that this "common
configuration" won't change with the next generation of consoles.

By imposing limits now, you are artificially constraining the API.

> Apple platforms native Game Controller API's:
> https://developer.apple.com/library/ios/documentation/ServicesDiscovery/Conceptual/GameControllerPG/Introduction/Introduction.html

On the one hand, this isn't really applicable; they are artificially
constraining the hardware. On the other... their artificial constraints
*don't match* yours. That should be a red flag right there...

> So I do not support expanding the scope of QtGamepad in the way you
> propose, as I think if it belongs anywhere it is in a generic input API
> (or you can always still just wrap SDL's input module pretty easily).

I might be more inclined to agree if there was already a QJoystick or
some such. As is, I think, at best, you're putting the cart before the
horse.

> There are however some API's missing that a gamepads API might
> actually need about like accelerometer based motion controls

If you supported arbitrary axes, *you'd have these already*.

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] some questions about QtGamePad

[Nichols Andy]

Hi Matthew, Pritam, et alia

QtGamepad is intentionally limited to gamepads, and does not include support 
for joysticks, or generic devices with an arbitrary number of axes/buttons.  
The design was primarily inspired by the HTML 5 gamepad API:
https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API/Using_the_Gamepad_API

Gamepads have roughly the same Button/Axes configurations and you can see this 
in the definitions of these similar API's:

Apple platforms native Game Controller API's:
https://developer.apple.com/library/ios/documentation/ServicesDiscovery/Conceptual/GameControllerPG/Introduction/Introduction.html

Android Game Contorllers:
http://developer.android.com/training/game-controllers/controller-input.html#button

And even the specialized SDL2 GameController module (which yes, does use the 
joystick API behind the scenes, but demonstrates the importance of the Gamepad 
specialization):
https://wiki.libsdl.org/CategoryGameController

So I do not support expanding the scope of QtGamepad in the way you propose, as 
I think if it belongs anywhere it is in a generic input API (or you can always 
still just wrap SDL's input module pretty easily).

There are however some API's missing that a gamepads API might actually need 
about like accelerometer based motion controls as well as haptic feedback, so 
during the tech preview phase this feedback and input is important, but I would 
like to reiterate the scope of this particular module before the discussion get 
too far off on a tangent (as it tends to do on this mailing list).

Regards,
Andy Nichols


From: Development  on behalf of Matthew 
Woehlke 
Sent: Monday, February 15, 2016 7:32 PM
To: development@qt-project.org
Subject: Re: [Development] some questions about QtGamePad

On 2016-02-15 13:04, Matthew Woehlke wrote:
> On 2016-02-15 06:36, pritam.ghang...@gmail.com wrote:
>> Looking at the API it seems it has a very hard assumption on 2 sticks and
>> 18 buttons.
>
> Please support arbitrary axes and buttons, as done in e.g. SDL.

I wrote a joystick API in Qt a while back. It had three signals (I
didn't get around to hat support):

  buttonPressed(int button);
  buttonReleased(int button);
  motion(QHash axisPosition);

The first two are obvious. The third (you'd probably want to use a
different name) is emitted every time any axis value changes, and
reports the current value of *all* axes. (This is an optimization /
implementation detail; you could as easily have a signal per axis, or
indeed do both.) Although I didn't need to have current-state accessors
(consider if you really need these), they'd be easy enough to add.

Hat support would probably look like:

  hatMoved(int hat, HatDirection direction);

Looking at QGamepadManager, I notice that you treat the hat as a set of
buttons. That doesn't strike me as a good idea. Buttons are normally
orthogonal (that is, given any two buttons, both might be pressed at the
same time). While it's true that you can be lazy and report hats that
way, there are problems doing so. First, it precludes users mapping an
entire hat to a single digital 2-axis control (or at least makes it much
more difficult). Second, hat directions are *not* orthogonal; a hat is
more of a digital version of an axis-pair, i.e. two values that are
either {-1, 0, +1}. This isn't just a matter of how you can mash on the
controller, it's also a question of what the hardware protocol is
capable of reporting.

--
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] some questions about QtGamePad

[Matthew Woehlke]

On 2016-02-15 13:04, Matthew Woehlke wrote:
> On 2016-02-15 06:36, pritam.ghang...@gmail.com wrote:
>> Looking at the API it seems it has a very hard assumption on 2 sticks and
>> 18 buttons.
> 
> Please support arbitrary axes and buttons, as done in e.g. SDL.

I wrote a joystick API in Qt a while back. It had three signals (I
didn't get around to hat support):

  buttonPressed(int button);
  buttonReleased(int button);
  motion(QHash axisPosition);

The first two are obvious. The third (you'd probably want to use a
different name) is emitted every time any axis value changes, and
reports the current value of *all* axes. (This is an optimization /
implementation detail; you could as easily have a signal per axis, or
indeed do both.) Although I didn't need to have current-state accessors
(consider if you really need these), they'd be easy enough to add.

Hat support would probably look like:

  hatMoved(int hat, HatDirection direction);

Looking at QGamepadManager, I notice that you treat the hat as a set of
buttons. That doesn't strike me as a good idea. Buttons are normally
orthogonal (that is, given any two buttons, both might be pressed at the
same time). While it's true that you can be lazy and report hats that
way, there are problems doing so. First, it precludes users mapping an
entire hat to a single digital 2-axis control (or at least makes it much
more difficult). Second, hat directions are *not* orthogonal; a hat is
more of a digital version of an axis-pair, i.e. two values that are
either {-1, 0, +1}. This isn't just a matter of how you can mash on the
controller, it's also a question of what the hardware protocol is
capable of reporting.

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Closing the 5.5 branch

[Liang Qi]

https://codereview.qt-project.org/146557 still need to be integrated.

On 8 February 2016 at 14:03, Frederik Gladhorn <
frederik.gladh...@theqtcompany.com> wrote:

> Hi all,
>
> due to the strain that we put on the VMs that are supposed to get the
> releases
> out and do the testing, we decided to "shut down" the CI for Qt 5.5
> branches.
> This means literally that we shut down the VMs but we'll keep them around
> in
> case we ever need to make a 5.5 release.
> The goal is to free capacity to let us finally get 5.6 and just after 5.7
> out
> of the door.
>
> Cheers,
> Frederik
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



-- 
http://www.qiliang.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] some questions about QtGamePad

[Matthew Woehlke]

On 2016-02-15 06:36, pritam.ghang...@gmail.com wrote:
> Looking at the API it seems it has a very hard assumption on 2 sticks and
> 18 buttons.

Please support arbitrary axes and buttons, as done in e.g. SDL.
Hard-coding this stuff is a terrible idea, as even devices with similar
physical configurations may number their inputs differently.
(Hard-coding the *nature* of the buttons, e.g. "home", "guide" is *also*
a terrible design; not all controllers have anything like these.)

Three controllers I have offhand have the following attributes:

  - 4 axes, 12 buttons, 1 hat
  - 5 axes, 8/9¹ buttons, 1 hat
  - 6 axes², 11 buttons, 1 hat

These are, respectively, a Logitech WingMan Rumble Pad, Logitech Extreme
3D Pro, and standard XBox 360 controller. (I do note that you're at
least treating the analog triggers as axes and not buttons.) Note that
the second in particular has *one* stick with *three* axes (plus a
throttle control).

How do you even handle hats???

Then there are e.g. standard Wii controllers which have, I think, 6/7²
axes (*none* of which are sticks), 6/7² buttons, and 1 hat. The nunchuck
has at *8* (or 9²) axis, 1/2² buttons, and no hat.

Please, *please* take the SDL approach and just support axes, buttons
and hats (all in arbitrary number) without trying to assign any
particular meaning to any of the above. (And keep in mind that axes can
be self-centering, i.e. sticks, triggers, acceleromaters, or not, i.e.
throttles, gyroscopes.) This way you support just about any device,
including a degree of future-proofing.

(¹ I think one of the buttons may be treated specially by the hardware
and not generally "visible". I don't have the pad with me to check, though.)

(² I don't have a Wii controller to test, and I'm not sure if the
trigger is analog (axis) or digital (button).)

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] some questions about QtGamePad

[Bogdan Vatra]

Hi,

  From a gamepad perspective it's almost complete. Yes I know that there are 
gamepads out there with more buttons, QtGamepad it's a technical preview, so 
we can change it. IMHO we just need to add a few more generic buttons/axes and 
that's it.

 I also agree with Mike that Qt needs some "generic" input device support, 
something similar with Android's InputDevice API 
(http://developer.android.com/reference/android/view/InputDevice.html), but 
that's another story.

Cheers,
BogDan.

On Monday 15 February 2016 14:08:56 Mike Krus wrote:
> +1, looking at it from the AppleTV remote perspective, it also needs support
> for handling device orientation (tilt sensors, etc)
> 
> 
> Mike
> 
> > On 15 Feb 2016, at 11:36, pritam.ghang...@gmail.com wrote:
> > 
> > Hi
> > 
> > I have looking at QtGamePad for usage in another opensource project
> > QGroundControl. It looks like a great module already, something that will
> > reduce lot of cross platform headache for a lot of people trying to use
> > joysticks with Qt. Awesome work by the authors.
> > 
> > Looking at the API it seems it has a very hard assumption on 2 sticks and
> > 18 buttons.  It is quite possible that QGrounControl may have to support
> > more than 2 sticks. Its quite common for robotics controller to have more
> > than 2 sticks in the form of other photometers. It would be good if some
> > more lower level cross platforms apis were exposed that allow one to
> > enumerate the sticks and buttons. Something that can give us more raw
> > data to handle such special cases.
> --
> Mike Krus | mike.k...@kdab.com | Senior Software Engineer
> KDAB (UK) Ltd., a KDAB Group company
> Tel: UK +44-1625-809908   Mobile: +44 7833 491941
> KDAB - The Qt Experts

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] some questions about QtGamePad

[Sean Harmer]

Hi,

On 15/02/2016 11:36, pritam.ghang...@gmail.com wrote:

Hi

I have looking at QtGamePad for usage in another opensource project 
QGroundControl. It looks like a great module already, something that 
will reduce lot of cross platform headache for a lot of people trying 
to use joysticks with Qt. Awesome work by the authors.


Looking at the API it seems it has a very hard assumption on 2 sticks 
and 18 buttons.  It is quite possible that QGrounControl may have to 
support more than 2 sticks. Its quite common for robotics controller 
to have more than 2 sticks in the form of other photometers. It would 
be good if some more lower level cross platforms apis were exposed 
that allow one to enumerate the sticks and buttons. Something that can 
give us more raw data to handle such special cases.


We have some API in Qt 3D for this:

http://code.qt.io/cgit/qt/qt3d.git/tree/src/input/frontend/qabstractphysicaldevice.h?h=5.7

We can look at making it available to more parts of Qt in the future but 
at the moment the implementation is tied to Qt 3D's architecture. We've 
tried this with Playstation 3 six axis controllers as well as 
SpaceNavigator Pro 3D mice. There is already a commit in that provides 
this on top of Andy's great QtGamepad efforts.


Cheers,

Sean



--
Regards,
pritam


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] some questions about QtGamePad

[Mike Krus]

+1, looking at it from the AppleTV remote perspective, it also needs support 
for handling device orientation (tilt sensors, etc)


Mike


> On 15 Feb 2016, at 11:36, pritam.ghang...@gmail.com wrote:
> 
> Hi
> 
> I have looking at QtGamePad for usage in another opensource project 
> QGroundControl. It looks like a great module already, something that will 
> reduce lot of cross platform headache for a lot of people trying to use 
> joysticks with Qt. Awesome work by the authors.
> 
> Looking at the API it seems it has a very hard assumption on 2 sticks and 18 
> buttons.  It is quite possible that QGrounControl may have to support more 
> than 2 sticks. Its quite common for robotics controller to have more than 2 
> sticks in the form of other photometers. It would be good if some more lower 
> level cross platforms apis were exposed that allow one to enumerate the 
> sticks and buttons. Something that can give us more raw data to handle such 
> special cases.
> 
> -- 
> Regards,
> pritam
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Mike Krus | mike.k...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel: UK +44-1625-809908   Mobile: +44 7833 491941
KDAB - The Qt Experts



smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] some questions about QtGamePad

[pritam.ghang...@gmail.com]

I meant potentiometers not photometers in there.

On Mon, Feb 15, 2016 at 5:06 PM, pritam.ghang...@gmail.com <
pritam.ghang...@gmail.com> wrote:

> Hi
>
> I have looking at QtGamePad for usage in another opensource project
> QGroundControl. It looks like a great module already, something that will
> reduce lot of cross platform headache for a lot of people trying to use
> joysticks with Qt. Awesome work by the authors.
>
> Looking at the API it seems it has a very hard assumption on 2 sticks and
> 18 buttons.  It is quite possible that QGrounControl may have to support
> more than 2 sticks. Its quite common for robotics controller to have more
> than 2 sticks in the form of other photometers. It would be good if some
> more lower level cross platforms apis were exposed that allow one to
> enumerate the sticks and buttons. Something that can give us more raw data
> to handle such special cases.
>
> --
> Regards,
> pritam
>



-- 
Regards,
pritam
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Proposal] Future QtSerialPort with plugins architecture

[Denis Shienkov]

> 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 clarity",
but I don't know
how I can divide a code. I need help...

BR,
Denis


2016-02-15 14:35 GMT+03:00 Oswald Buddenhagen <
oswald.buddenha...@theqtcompany.com>:

> 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., plugins. 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.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] some questions about QtGamePad

[pritam.ghang...@gmail.com]

Hi

I have looking at QtGamePad for usage in another opensource project
QGroundControl. It looks like a great module already, something that will
reduce lot of cross platform headache for a lot of people trying to use
joysticks with Qt. Awesome work by the authors.

Looking at the API it seems it has a very hard assumption on 2 sticks and
18 buttons.  It is quite possible that QGrounControl may have to support
more than 2 sticks. Its quite common for robotics controller to have more
than 2 sticks in the form of other photometers. It would be good if some
more lower level cross platforms apis were exposed that allow one to
enumerate the sticks and buttons. Something that can give us more raw data
to handle such special cases.

-- 
Regards,
pritam
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Proposal] Future QtSerialPort with plugins architecture

[Oswald Buddenhagen]

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., plugins. 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.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QAccessibleQuickItem setText

[manish sharma]

I was exploring accessibility options to run some automation and looks like
setting text to an item is not implemented in QAccessibleQuickItem which is
preventing me from setting text to text items.

https://code.woboq.org/qt5/qtdeclarative/src/quick/accessible/qaccessiblequickitem_p.h.html#83

And also it looks like windows plugins does not implement put_accName

https://code.woboq.org/qt5/qtbase/src/plugins/platforms/windows/accessible/qwindowsmsaaaccessible.cpp.html#905

Any plans of getting this issue addressed? Or Is there any other way to set
text to an quick Item?

Thanks,
Manish
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Request for a new playground project

[Rutledge Shawn]

And then “backend” is awfully vague, could be anything other than application 
UI.  (QPA is a kind of backend, so is ODBC.)  Yes it’s a buzzword, but will it 
sound too dated or even more vague in 10 years?

> On 15 Feb 2016, at 07:30, Petroules Jake  
> wrote:
> 
> Drop the "mobile". Qt is a cross platform project and there does not seem to 
> be any technical reason to restrict this to mobile platforms. So, just 
> "Backend as a Service".
> 
>> On Feb 14, 2016, at 3:54 AM, Guillaume Charbonnier 
>>  wrote:
>> 
>> Hi all !
>> 
>> Following my last message regarding Qt new module for "Mobile Backend as a 
>> Service », what is the procedure to follow for creating a Qt playground 
>> project ?
>> My project is in a very early phase, it can only support REST api of 
>> Firebase for now but I felt it could help to mutualize our effort if we 
>> could have a published playground project.
>> 
>> Best regards.
>> Guillaume
>> 
>>> Le 12 févr. 2016 à 14:54, Guillaume Charbonnier 
>>>  a écrit :
>>> 
>>> Hi all,
>>> 
>>> Following engin.io services ramping down notification, Qt mobile developers 
>>> (like me) are lacking a MBaaS (mobile backend as a service) that would play 
>>> nicely with Qt. 
>>> I think this lack could be quite a big impedance for the promotion of Qt 
>>> for mobile development as most mobile applications use the basic features a 
>>> MBaaS offer...
>>> 
>>> I would like to start a playground project (with the help of everyone 
>>> interested in that topic) to offer a set of Qt classes and QML elements to 
>>> manage the following services :
>>> • authentification and authorization (with social login)
>>> • datastore (nosql)
>>> • push notifications
>>> • statistics
>>> 
>>> I think it would be great to design this new module to be backend agnostic. 
>>> Thus supporting several backend providers such as :
>>> - google Firebase
>>> - BaasBox
>>> - IBM Cloudant
>>> - Apigee
>>> 
>>> I have never participate in Qt project so I am an absolute beginner in this 
>>> field. 
>>> I have read the development topics in the wiki despite some of them state 
>>> to be outdated - any advice and recommandation will be greatly appreciated.
>>> Here is a link to the corresponding forum topic : 
>>> https://forum.qt.io/topic/63777/looking-for-engin-io-replacement-joining-our-effort-initiative
>>> 
>>> To conclude, I think it would be helpful to create a playground project for 
>>> this project, hence my request :
>>> Description : Qt Mobile Backed as a Service
>>> Playground project name : MBaaS
>>> 
>>> Best regards.
>>> Guillaume
>> 
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> -- 
> Jake Petroules - jake.petrou...@theqtcompany.com
> Consulting Services Engineer - The Qt Company
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Proposal] Future QtSerialPort with plugins architecture

[Denis Shienkov]

> 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