· Page d'accueil · Toutes les classes · Toutes les fonctions · Vues d'ensemble ·

Determining the default sensor for a type

Multiple sensors can exist for a type

Sensors was designed so that multiple sensors could exist for a given type. Why? Consider this example.

The N900 has an accelerometer built-in. It also features bluetooth and can pair with a gaming controller that features an accelerometer. To a developer writing a game these two devices are conceptually the same type.

Default sensor for a type

To avoid the need to know (or check) what the default sensor for a type is, the system will use the default sensor for a type. Most of the time this is what the app developer wants to do. In cases where the app developer wants to select a specific sensor they must call the QSensor::setIdentifier() method before they start the sensor so that the appropriate backend is used.

From a system perspective though, selecting which sensor should be the default gets tricky. The sensors library uses the first registered identifier as the default. This means that the order in which sensor backends are registered is important so the system will allow a config file to determine the default instead.

Sensors.conf

The config file that determines the default sensor for a type is called Sensors.conf. If present, it is located in /etc/xdg/Nokia. It is read using QSettings so it has the standard formatting of a QSettings .conf file.

The settings live in the Default group and the general format is:

 type = identifier

An example Sensors.conf that ensures the N900 accelerometer is used as the default no matter the order in which backends were registered is presented here.

 [Default]
 QAccelerometer = n900.accelerometer

If Sensors.conf specifies an identifier that is not registered then the system will fall back to the first registered identifier as the default.

Note that there is special case logic to prevent the generic plugin's backends from becoming the default when another backend is registered for the same type. This logic means that a backend identifier starting with generic. will only be the default if no other backends have been registered for that type or if it is specified in Sensors.conf.

Best Of

Actualités les plus lues

Semaine

Mois

Année

Le Qt Quarterly au hasard

Bibliothèques et plug-ins

Qt Quarterly est la revue trimestrielle proposée par Nokia et à destination des développeurs Qt. Ces articles d'une grande qualité technique sont rédigés par des experts Qt. Lire l'article.

Communauté

Ressources

Liens utiles

Contact

Vous souhaitez rejoindre la rédaction ou proposer un tutoriel, une traduction, une question... ? Postez dans le forum Contribuez ou contactez-nous par MP ou par email (voir en bas de page).

Qt dans le magazine

Cette page est une traduction d'une page de la documentation de Qt, écrite par Nokia Corporation and/or its subsidiary(-ies). Les éventuels problèmes résultant d'une mauvaise traduction ne sont pas imputables à Nokia.	Qt qtmobility-1.2
Copyright © 2012 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon, vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.
Vous avez déniché une erreur ? Un bug ? Une redirection cassée ? Ou tout autre problème, quel qu'il soit ? Ou bien vous désirez participer à ce projet de traduction ? N'hésitez pas à nous contacter ou par MP !