On 20/11/2012, at 6:20 PM, Knoll Lars <lars.kn...@digia.com> wrote:

> Hi Lorn,
> 
> On Nov 20, 2012, at 1:42 AM, Lorn Potter <lorn.pot...@gmail.com> wrote:
> 
>> 
>> On 20/11/2012, at 6:09 AM, Knoll Lars <lars.kn...@digia.com> wrote:
>> 
>>> 
>>> The beta2 is a very good milestone towards Qt 5. We now have packages that 
>>> include the full content of what we agreed to ship, including Qt Creator. 
>>> Also our bug numbers are looking ok, with ~50 P0 and P1 bugs left for 5.0.
>> 
>> How about re-adding QSensors for 5.0?
> 
> I'm happy to re-add them for a subsequent 5.0.x release, but please 
> understand that it's too late for 5.0.0. We have been asking publicly about 
> this on the mailing list, and since nobody raised his hand for the module, it 
> was left out.
>> 

There was no mention that this meant those modules would basically be stricken 
from git and/or the build system , and made more difficult to obtain or even 
work on these modules.
I was under the impression this only meant the release _package_, not the 
development build system.

That, and the change that actually removed these modules from the build system 
did not even seek reviews from the modules maintainers. 

So I got a rude awakening when I updated the repos, and tried my usual
make module-qtsensors.




>> I also noticed that QSensors 5 is completely missing from the docs 
>> http://qt-project.org/doc/qt-5.0/modules.html
>> 
>> QSensors not even listed as an add-on module any more.
> 
> Yes, docs are currently being generated for the modules that are included, 
> but I wouldn't mind a patch that adds a link to these as external modules. 
> Longer term, I'd prefer if we make this more modular, and we can install 
> these modules including docs on the fly.
>> 
>> Neither are any of the recently 'removed' modules/classes listed there.
>> How about listing _ALL_ of Qt/modules, regardless of maintainership or 
>> 'release' status?
> 
> The infrastructure we have currently simply makes this rather difficult. But 
> some of them simply don't even make sense to list in their current status 
> (e.g. docgallery). For the others we'd have to be very careful in listing 
> them with correct status. 
>> 
>> Especially the changes to qt.pro and init-repository make finding them very 
>> difficult, and they are then doomed into obscurity of finding no maintainer.
> 
> There's a change pending by Ossi to add them to qt5.git again. I'm ok with 
> the change in principal, but would like to avoid anything that makes it 
> harder to get 5.0.0 out just now.
>> 
>> I can understand those modules where no one is going to maintain them, but 
>> please, there are a few modules that got removed that _do_ have active 
>> maintainers, just not Digia ones. QConnectivity, QSensors and QSystems for 
>> example. 
> 
> This has *nothing* to do with Digia. Many other modules we release have 
> maintainers outside of Digia as well. It has everything to do with us asking 
> on the mailing list for commitment to support a module for 5.0.0 and not 
> getting that for these modules.

Perhaps there needs to be a maintainers email list for very important emails 
such as this that might get lost in the noise.


>> 
>> Isn't BB10 supposed to become a Tier 1 platform? QSensors are a part of BB10.
> 
> Yes. I've told you that before, I'll re-iterate it: My goal is to get Sensors 
> and some of the other modules back into the official release. We've said that 
> with modularisation, modules can have different release schedules. So adding 
> them in an update to the SDK should not be a problem.
> 
> What I would however like to see for these modules is another backend apart 
> from BB10.

There is. A basic generic, a simulator and a generic linux backend. Also a wii 
controller backend WIP.


> We're now working on Android and iOS, and it would be good if we can validate 
> that the API works for these.


Android port has been using the qtmobility sensors API for some time now. iOS 
only contains accelerometer and proximity in the public API. iOS light sensor 
is current hidden within private headers. The API does not need to be validated 
against these platforms. It will work fine.

Windows 8 has sensor API's too.


> 
> Cheers,
> Lars
> 

Lorn Potter
Senior Software Engineer, QtSensors/QtSensorGestures




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

Reply via email to