|
|
              
PluginThe Plugin element describes a Location based services plugin. More... Inherits QtObject This type was introduced in Qt Location 5.0. Properties
Methods
Detailed DescriptionThe Plugin element is used to declaratively specify which available GeoServices plugin should be used for various tasks in the Location API. Plugins are used by Map, RouteModel, and GeocodeModel elements, as well as a variety of others. Plugins recognized by the system have a name property, a simple string normally indicating the name of the service that the Plugin retrieves data from. They also have a variety of features, which can be enumerated using the supported property. When a Plugin element is created, it is "detached" and not associated with any actual service plugin. Once it has received information via setting its name, preferred, or required properties, it will choose an appropriate service plugin to attach to. Plugin elements can only be attached once; to use multiple plugins, create multiple Plugin elements. Example UsageThe following snippet shows a Plugin element being created with the required and preferred properties set. This Plugin will attach to the first plugin found plugin that supports both mapping and geocoding, and will prefer plugins named "nokia" or "foo" to any others. Plugin {
id: plugin
preferred: ["nokia", "foo"]
required: Plugin.MappingFeature | Plugin.GeocodingFeature
}
Property DocumentationThis property indicates if experimental plugins can be used. This property indicates if the Plugin is attached to another Plugin. This property contains an ordered list of preferred plugin locales. If the first locale cannot be accommodated, then the backend falls back to using the second, and so on. By default the locales property contains the system locale. The locales are specified as strings which have the format "language[_script][_country]" or "C", where:
If the first specified locale cannot be accommodated, the Plugin falls back to the next and so forth. Some Plugin backends may not support a set of locales which are rigidly defined. An arbitrary example is that some Place's in France could have French and English localizations, while certain areas in America may only have the English localization available. In the above scenario, the set of supported locales is context dependent on the search location. If the Plugin cannot accommodate any of the preferred locales, the manager falls back to using a supported language that is backend specific. For Plugin's that do not support locales, the locales list is always empty. The following code demonstrates how to set a single and multiple locales: //single locale Plugin { locales: "en_US" } //multiple locales Plugin { locales: ["fr_FR","en_US"] } This property holds the name of the plugin. Setting this property will cause the Plugin to only attach to a plugin with exactly this name. The value of required will be ignored. This property holds the list of plugin parameters. This property contains an ordered list of preferred plugin names, which will be checked for the required features set in required before any other available plugins are checked. This property contains the set of features that will be required by the Plugin element when choosing which service plugin to attach to. If the name property is set, this has no effect. Any of the following values or a bitwise combination of multiple values may be set:
Method DocumentationThis method returns a boolean indicating whether the specified set of features flags is supported or not. True is returned if it is supported, otherwise false is returned. The features parameter can be any flag combination of:
|
