Documentation update

* Make the documentation less automotive specific
* Give more examples where the zones concept is useful
* Add a better overview documentation to:
  QIfAbstractZonedFeature
  QIfZonedFeatureInterface
  QIFeatureInterface

Task-number: QTBUG-99004
Task-number: QTBUG-116203
Change-Id: Icef354f97c5bf504abb3b93886e9866ed185e3d9
Reviewed-by: Robert Griebl <robert.griebl@qt.io>
(cherry picked from commit 174c70b7efdd50866a69c9795bf55ae6ce54e7d8)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit d76d2181ffcda5ed65e9d86cc1bc3ca16efe42f5)

9 files changed, 226 insertions, 145 deletions

diff --git a/src/interfaceframework/doc/src/backend-system.qdoc b/src/interfaceframework/doc/src/backend-system.qdoc
index 3b53fbd5..19be2259 100644
--- a/src/interfaceframework/doc/src/backend-system.qdoc
+++ b/src/interfaceframework/doc/src/backend-system.qdoc
@@ -9,13 +9,14 @@
 
     \section1 Feature
 
-    Modern automotive systems are very complex, usually developed on a strict time frame. Consequently,
-    it is efficient to reuse parts of previously developed systems, for a new system. At the same time,
-    the main development is done by independent companies (tier-1). To make it possible to reuse code
-    from previous projects, and also incorporate code from tier-1 partners, the APIs are split into two
-    layers: a front end and a back end. In the Qt Interface Framework, the front-end API is called a \b feature,
-    as usually a specific class is responsible for a specific feature area, such as QIfClimateControl, which
-    controls the climate feature area.
+    New software projects can easily get very complex and are usually developed on a strict time
+    frame. Consequently, it is efficient to reuse parts of previously developed systems, for a new
+    system. At the same time, the development is often split over various teams working on
+    different parts of the project. To make it possible to reuse code from previous projects, and
+    also incorporate code developed by other teams, the APIs are split into two layers: a front end
+    and a back end. In the Qt Interface Framework, the front-end API is called a \b feature, as
+    usually a specific class is responsible for a specific feature area, such as ClimateControl,
+    which controls the climate feature area.
 
     \section1 Back end
 
@@ -146,32 +147,27 @@
 
     \section1 Zoned Features
 
-    Zones are a standard way to provide a single API for multiple points in the vehicle. For instance,
-    climate control commonly has a driver zone and passenger zone; or even a back seat zone. The same
-    concept applies to:
+    Zones are a standard way to provide a single API for multiple points. For instance, a
+    climate control inside a house can be per room e.g. for the living-room and the bathroom. Those
+    rooms act as a zone. The same concept applies to:
     \list
-        \li wheels
-        \li doors
-        \li mirrors
-        \li windows
+        \li addressbooks for home and corporate use
+        \li several vehicles inside a fleet management system
+        \li windows, mirrors, air-conditioning inside a car
         \li and more...
     \endlist
 
-    A common pattern is to combine zones with property attributes to handle small differences in
-    capabilities between zones; for example, there's no steering wheel heater in a car's passenger side.
-
     Technically, a zoned feature consists of multiple instances of the same feature, a top-level
     instance which provides the zone-independent API and access to instances for a specific zone.
     The feature needs to derive from QIfAbstractZonedFeature and implement createZoneFeature() to
     provide zone-specific instances.
 
-    The top-level interface can provide vehicle wide settings. For example, whether re-circulation
-    should be used in a climate control API. In contrast, the zoned interface provides per-zone
-    functions, such as the desired temperature.
+    The top-level interface can provide system wide settings. For example, the outside temperature
+    and the weather-forecast. In contrast, the zoned interface provides per-zone
+    functions, such as the desired room temperature.
 
     Building a zoned feature requires the back-end interface to be derived from QIfZonedFeatureInterface.
     This class provides the back end with an interface to enumerate the zones available. This interface
     also includes the necessary QIfZonedFeatureInterface::initialize method to initialize any
     properties.
-
 */
diff --git a/src/interfaceframework/doc/src/extending-qtif.qdoc b/src/interfaceframework/doc/src/extending-qtif.qdoc
index 8a139e6d..bca6d955 100644
--- a/src/interfaceframework/doc/src/extending-qtif.qdoc
+++ b/src/interfaceframework/doc/src/extending-qtif.qdoc
@@ -19,12 +19,12 @@ development and testing purposes.
 
 \section1 The Big Picture
 
-Qt Interface Framework consists of three types of building blocks. The core module provides base classes
-and common code for all the more specific modules and API definitions like a climate API
-or a media player API. Each of these APIs is the second building block called \e Feature,
-which defines the API used by the application developers. The last block consists of a
-back-end interface and one or more \e back ends implementing it to either connect to the
-underlying vehicle or do a simulation of it.
+Qt Interface Framework consists of three types of building blocks. The core module provides base
+classes and common code for all the more specific modules and API definitions like a climate API or
+a media player API. Each of these APIs is the second building block called \e Feature, which
+defines the API used by the application developers. The last block consists of a back-end interface
+and one or more \e back ends implementing it to either connect to the underlying service or to a
+simulation of it.
 
 \section2 Features
 
@@ -32,8 +32,8 @@ A feature is a set of classes for working with a specific function. It defines t
 towards application developers, but it does not implement the complete functionality. Instead, it
 defines a back-end interface to be implemented by a back end providing the actual functionality.
 
-For easy deployment, Qt Interface Framework extensions should be built as Qt modules. This makes it easy to
-install and find headers, shared libraries, and plugin modules from app projects.
+For easy deployment, Qt Interface Framework extensions should be built as Qt modules. This makes it
+easy to install and find headers, shared libraries, and plugin modules from app projects.
 
 By using the module system the developer can easily enable the inclusion of his
 module in the following way:
@@ -49,7 +49,7 @@ make tests
 \endcode
 
 When creating a new Qt Interface Framework module, it is recommended that you pick a name such as
-\e {OemFeatureName}, where \e {Oem} is the name of the car maker or platform owner, and
+\e {PlatformFeatureName}, where \e {Platform} is the name of the platform or product, and
 \e {FeatureName} is the name of the feature(s) of the module. In addition to the name, a reverse
 domain name prefix is needed for prefixing back-end interface names, for example \e {com.example}
 
diff --git a/src/interfaceframework/doc/src/ifcodegen/generator-usage.qdoc b/src/interfaceframework/doc/src/ifcodegen/generator-usage.qdoc
index 608af873..9213f6a6 100644
--- a/src/interfaceframework/doc/src/ifcodegen/generator-usage.qdoc
+++ b/src/interfaceframework/doc/src/ifcodegen/generator-usage.qdoc
@@ -297,7 +297,7 @@
                 that exports all enums to QML.
         \row
             \li \code
-                @designer: {categoryName: "QtInterfaceFramework - Vehicle Functions"}
+                @designer: {categoryName: "Smart Home Components"}
                 \endcode
             \li Main IDL file
             \li Module, Interface
@@ -330,7 +330,7 @@
                 \note The icon needs to be copied to the correct folder by a custom qmake rule.
         \row
             \li \code
-                @config: { configurationId: "vehiclefunctions"}
+                @config: { configurationId: "smarthome"}
                 \endcode
             \li Main IDL file
             \li Module, Interface
@@ -359,7 +359,7 @@
             \li
             \code
             config_simulator:
-                serviceObjectId: "vehiclefunctions_simulation"
+                serviceObjectId: "smarthome_simulation"
             \endcode
             \li Accompanying YAML file
             \li Module
@@ -369,7 +369,7 @@
             \li
             \code
             config_simulator:
-                configurationId: "vehiclefunctions"
+                configurationId: "smarthome"
             \endcode
             \li Accompanying YAML file
             \li Module
@@ -404,9 +404,9 @@
             \li
             \code
             config_simulator:
-                zones: [ FrontLeft,
-                         FrontRight,
-                         Rear ]
+                zones: [ Left,
+                         Right
+                       ]
             \endcode
             \li Accompanying YAML file
             \li Interface
@@ -418,8 +418,8 @@
             \code
             config_simulator:
             default:
-                AirflowDirection.Floor |
-                AirflowDirection.Dashboard
+                MyFlag.Value1 |
+                MyFlag.Value2
             \endcode
             \li Accompanying YAML file
             \li Property
@@ -430,8 +430,8 @@
             \code
             config_simulator:
             default: {
-                FrontLeft: 21.0,
-                FrontRight: 22.5,
+                Left: 21.0,
+                Right: 22.5,
                 =: 0.0
             }
             \endcode
@@ -497,7 +497,7 @@
             \li
             \code
             config_qtro:
-                serviceObjectId: "vehiclefunctions_qtro"
+                serviceObjectId: "smarthome_qtro"
             \endcode
             \li Accompanying YAML file
             \li Module
@@ -507,7 +507,7 @@
             \li
             \code
             config_qtro:
-                configurationId: "vehiclefunctions"
+                configurationId: "smarthome"
             \endcode
             \li Accompanying YAML file
             \li Module
diff --git a/src/interfaceframework/doc/src/qtif.qdoc b/src/interfaceframework/doc/src/qtif.qdoc
index aef153a5..3230b73d 100644
--- a/src/interfaceframework/doc/src/qtif.qdoc
+++ b/src/interfaceframework/doc/src/qtif.qdoc
@@ -21,8 +21,8 @@
     mediaplayer API. Each of these APIs is the second building block called
     \e Features, which define the API exposed to the application developer.
     \li The last block consists of a \e{back-end interface} and one or more
-    \e{back ends} implementing it to either connect to the underlying vehicle
-    or do a simulation of it.
+    \e{back ends} implementing it to either connect to the underlying service
+    or to a simulation of it.
     \endlist
 
     Qt Interface Framework is built around a pattern that separates the \e feature
diff --git a/src/interfaceframework/doc/src/qtinterfaceframework.qdoc b/src/interfaceframework/doc/src/qtinterfaceframework.qdoc
index b15c11d3..999de72a 100644
--- a/src/interfaceframework/doc/src/qtinterfaceframework.qdoc
+++ b/src/interfaceframework/doc/src/qtinterfaceframework.qdoc
@@ -28,14 +28,15 @@
 */
 
 /*!
-    \qmlmodule QtInterfaceFramework 1.0
+    \qmlmodule QtInterfaceFramework
     \title Qt Interface Framework Core QML Types
     \ingroup qmlmodules
     \ingroup qtif_qmlmodules
 
     \brief QML types for the Qt Interface Framework Core API.
 
-    The Qt Interface Framework Core QML API provides core functions for in-vehicle infotainment QML types.
+    The Qt Interface Framework Core QML API provides types which are used together with your own
+    API.
 
     To import the QML types into your application, use the following import statement
     in your .qml file:
diff --git a/src/interfaceframework/doc/src/reference-api.qdoc b/src/interfaceframework/doc/src/reference-api.qdoc
index 561c3a0b..f811ae39 100644
--- a/src/interfaceframework/doc/src/reference-api.qdoc
+++ b/src/interfaceframework/doc/src/reference-api.qdoc
@@ -10,8 +10,8 @@
 
 The Qt Interface Framework module contains a reference API that provides interfaces to common automotive
 functionality. These APIs rely on the separation of the front-end API from the back-end
-implementation. The Qt Interface Framework module also introduces a set of concepts used in the APIs, such as
-zones and property attributes. For more about concepts, see \l{Concepts and Architecture}.
+implementation. The Qt Interface Framework module also introduces a set of concepts used in the APIs
+which are described in \l{Concepts and Architecture}.
 
 \section1 Modules
 
diff --git a/src/interfaceframework/qifabstractzonedfeature.cpp b/src/interfaceframework/qifabstractzonedfeature.cpp
index bdd0b533..2b09e3bc 100644
--- a/src/interfaceframework/qifabstractzonedfeature.cpp
+++ b/src/interfaceframework/qifabstractzonedfeature.cpp
@@ -21,24 +21,100 @@ QIfAbstractZonedFeaturePrivate::QIfAbstractZonedFeaturePrivate(const QString &in
     \class QIfAbstractZonedFeature
     \inmodule QtInterfaceFramework
 
-    \since 5.6
+    \brief The QIfAbstractZonedFeature is the base class for all zoned features.
 
-    \brief The QIfAbstractZonedFeature is the base class for all QtInterfaceFramework vehicle features.
+    Subclass QIfAbstractZonedFeature to create an API with several zones. See \l{Zoned Features} for
+    usecases were this concept can be useful.
 
-    QIfAbstractZonedFeature contains all feature attributes and zone handling.
+    \section1 Implementation
+
+    A derived class needs to implement the createZoneFeature function which is responsible for
+    instantiating the class used for the given zone. In the simplest form, the same class is
+    allocated, passing on the \e zone argument to its constructor:
+
+    \code
+    class QIfClimateControl : public QIfAbstractZonedFeature {
+
+        ...
+
+        explicit QIfClimateControl(const QString &zone = QString(), QObject *parent = nullptr)
+            : QIfAbstractZonedFeature(QIfClimateControl_iid, zone, parent)
+        {
+        }
+
+    protected:
+        QIfAbstractZonedFeature *createZoneFeature(const QString &zone) override
+        {
+            new QIfClimateControl(zone, this);
+        }
+    }
+    \endcode
+
+    For the derived class, the same backend connection calls are made in the same order as specified
+    in QIfAbstractFeature and \l {Detailed Connection Order}. This applies also for the zone
+    instances, which use the passed zone argument to identify the signals in the backendinterface
+    belonging to this zone.
+
+    See QIfZonedFeatureInterface for how a backend needs to be implemented and how it can handle
+    zone specific properties.
+
+    \section2 Zone specific instance
+
+    Using the simple form described above, together with handling zone specific properties in the
+    backend has some down-sides. As the API is the same for the front-facing API and all its zones,
+    the developer using such an API cannot identify which properties/functions are zone specific.
+
+    There are two solutions for the problem, which are best used together to provide the most
+    versatile API.
+
+    \section3 Implement an isXAvailable function for each zone functionality
+
+    Add an extra property for each zone functionality to specify whether the functionality is
+    available. A developer can use such a property in the UI the hide the relevant UI elements on
+    the fly, instead of hardcoding it based on a zone name or relying on the error mechanism
+    described in the \l{QIfZonedFeatureInterface}{Setter implementation}.
+
+    \section3 Instantiate a custom class in createZoneFeature
+
+    By instantiating a custom class in createZoneFeature, the API for zoned and unzoned features
+    can be split over two classes. The unzoned functionality is implemented in the front-facing API,
+    while all zone specific functions are implemented in the Zone class which is returned by
+    createZoneFeature().
+
+    \section1 Usage
+
+    Once the backend is connected, the availableZones property can be used to retrieve all currently
+    available zones. A specific zone can be accessed using the zoneAt() function or by using the
+    zones function, which returns all zones in a list.
 */
 
 /*!
     \qmltype AbstractZonedFeature
     \instantiates QIfAbstractZonedFeature
-    \inqmlmodule QtInterfaceFramework 1.0
+    \inqmlmodule QtInterfaceFramework
     \inherits AbstractFeature
     \brief The AbstractZonedFeature is not directly accessible. The QML type provides
-    base QML properties for each QML Vehicle feature like zone and error access.
+    base QML properties for all zoned features.
+
+    AbstractZonedFeature provides an API to access all the available zones.
+
+    Once the backend is connected, the \l availableZones property can be used to learn about all
+    currently available zones. A specific zone can be accessed using the \l zoneAt property or by
+    using the zones property which returns all zones in a list.
+
+    \code
+    ClimateControl{
+        id: climateControl
+    }
+
+    Text {
+        text: climateControl.zoneAt.FrontLeft.temperature
+    }
+    \endcode
 */
 
 /*!
-    Constructs a vehicle feature with a specific \a interface and \a zone.
+    Constructs a zoned feature with a specific \a interface and \a zone.
 
     If \a parent is of type QIfAbstractZonedFeature, then the created instance
     uses parent for the backend connection. Parent is connected to the
diff --git a/src/interfaceframework/qiffeatureinterface.cpp b/src/interfaceframework/qiffeatureinterface.cpp
index 5eff9f66..260bd962 100644
--- a/src/interfaceframework/qiffeatureinterface.cpp
+++ b/src/interfaceframework/qiffeatureinterface.cpp
@@ -14,17 +14,64 @@ QT_BEGIN_NAMESPACE
 
     \brief QIfFeatureInterface defines the base class for all backends.
 
-    To implement a backend for a specific feature you need to derive from this class.
-    There's a one-to-one mapping between a spezialized feature API and its corresponding feature interface
+    To implement a backend for a specific feature, you need to derive from this class. There's a
+    one-to-one mapping between a specialized feature API and its corresponding feature interface
     class.
 
-    The feature interface class specifies which functions and signals need to be implemented by a backend
-    to work with a specific feature.
-
-    This base class contains the generic error handling, which is common between all interfaces.
-
-    See the full example backend implementation from \c {src/plugins/ifvehiclefunctions/climate_simulator}.
-    \sa QIfAbstractFeature, QIfServiceInterface
+    The feature interface class specifies which functions and signals need to be implemented by a
+    backend to work with a specific feature.
+
+    This base class contains the initialization logic and the generic error handling, which is
+    common between all interfaces.
+
+    A feature interface for coffee machine could look like this:
+    \code
+    class CoffeMachineInterface : public QIfFeatureInterface
+    {
+        void setTargetTemperature(int targetTemperature) = 0;
+        ...
+
+    signals:
+        void currentTemperatureChanged(int currentTemperature);
+        void targetTemperatureChanged(int targetTemperature);
+        ...
+    }
+    \endcode
+
+    A backend implementation providing the actual functionality needs to implement all pure-virtual
+    functions and the logic to provide property updates and their initial state. Once the feature
+    knows which backend implementation needs to be used, it will request the initial state of all
+    properties by calling the \l initialize() function. The implementation needs to emit the changed
+    signals with the initial values and once it is done, emit the \l initializationDone signal.
+
+    In the coffee machine example the implementation could look like this:
+
+    \code
+    class CoffeMachineImplementation : public CoffeMachineInterface
+    {
+        void initialize()
+        {
+            emit currentTemperature(0);
+            emit targetTemperature(0);
+            emit initializationDone();
+        }
+
+        void setTargetTemperature(int targetTemperature)
+        {
+            if (m_targetTemperature == targetTemperature)
+                return;
+
+            // adjust the heating element to the new target temperature
+            emit targetTemperatureChanged(targetTemperature)
+        }
+    }
+    \endcode
+
+    The implementation for \e setTargetTemperature() controls the internal heating element and once
+    that is done, the change signal is emitted to inform the feature about the new state of the
+    property.
+
+    \sa QIfAbstractFeature
 */
 
 QIfFeatureInterface::QIfFeatureInterface(QObject *parent)
diff --git a/src/interfaceframework/qifzonedfeatureinterface.cpp b/src/interfaceframework/qifzonedfeatureinterface.cpp
index f7d4bc1c..000a0609 100644
--- a/src/interfaceframework/qifzonedfeatureinterface.cpp
+++ b/src/interfaceframework/qifzonedfeatureinterface.cpp
@@ -12,62 +12,63 @@ QT_BEGIN_NAMESPACE
     \inmodule QtInterfaceFramework
     \ingroup backends
 
-    \brief QIfZonedFeatureInterface defines the base interface for the
-    feature backend classes.
-
-    Vehicle feature can be zoned or be just generic depending of the vehicle.
-    For example some vehicles can contain only one climate fan and some other
-    may have one fan for the front seats and one for the back seat. To fill both
-    requirements, a backend developer can specify each feature attribute to be
-    generic or zone specific. If the backend doesn't specify a zone for an
-    attribute, then the attribute is generic. There can be multiple zone
-    attributes, but only a single generic one. The zone value for a generic
-    attribute is an empty string, and it can be omitted from the signals. The
-    code snippets below describes how to implement zone specific fanSpeedlevel
-    and generic steeringWheelHeater support in the backend.
+    \brief QIfZonedFeatureInterface defines the base interface for all
+    QIfAbstractZonedFeature derived classes.
+
+    Implementing QIfZonedFeatureInterface follows the same pattern as described in
+    QIfFeatureInterface, but to support zones some additional functions need to be implemented: all
+    setters and signals which are zoned need to be adapted like described below.
 
     \section2 Providing Available Zones
 
-    Before making any further calls to the backend, VehicleFunctions will query
+    Before making any further calls to the backend, The zoned feature will query
     the list of available zones. Zones are string keys and can be anything
-    defined by the backend developer. In this case we have two zones: "Front"
-    and "Rear".
+    defined by the backend developer. In this case we have two zones: "Left"
+    and "Right":
 
-    The backend must return all available zones via
-    \l {QIfZonedFeatureInterface::}{availableZones}:
     \code
-    QStringList backend::availableZones() const {
+    QStringList Backend::availableZones() const {
         QStringList zones;
-        zones << "Front";
-        zones << "Rear";
+        zones << "Left";
+        zones << "Right";
         return zones;
-   }
+    }
     \endcode
 
-    \section2 Initializing Attributes
+    \section2 Signal Definition
+
+    A zoned signal or a change signal for a zoned property needs to provide the zone as the second
+    parameter. Here an example for a zoned signal:
+
+    \code
+    void fanSpeedLevelChanged(int value, const QString &zone);
+    \endcode
 
-    VehicleFunctions calls the backend to initialize all attributes. Backend
-    implementation has to emit all supported attribute signals, passing the
-    zone as a parameter. Zone is not needed if attribute is generic.
+    Similar to implementing a QIfFeatureInterface, the backend needs to emit all property change
+    signals with the initial values in the \l initialize() function.
+    In a zoned backend, the implementation has to emit all supported property signals, passing the
+    zone as a parameter. The zone parameter can be omitted if the property is unzoned.
 
-    Initialization signals are emitted in the
-    \l {QIfZonedFeatureInterface::}{initialize}:
     \code
-    void backend::initialize() {
-        emit fanSpeedLevelChanged(2, "Front");
-        emit fanSpeedLevelChanged(2, "Rear");
+    void Backend::initialize() {
+        emit fanSpeedLevelChanged(2, "Left");
+        emit fanSpeedLevelChanged(2, "Right");
         emit steeringWheelHeaterChanged(0); // Generic, no zone specified
         emit initializationDone();
-   }
+    }
     \endcode
 
-    \section2 Implementing Feature-specific Attributes
+    \section2 Setter implementation
+
+    A setter for a zoned property takes the zone as the second parameter after the property value.
+    Validating the requested zone is the responsibility of the backend implementation and in case
+    an unsupported zone is passed, a \l QIfAbstractFeature::InvalidZone error should be reported.
 
-    Fan speed is zoned, validating requested zones is the responsibility
-    of the backend. If zone is valid, the vehicle's actual fan speed level
-    can be adjusted. The backend has to emit a signal for the changed zone.
+    In the example, the \e fanSpeedLevel property is zoned. If \e zone is valid, the actual fan
+    speed level is adjusted and afterwards the change signal is emitted to indicate the change to
+    the feature.
     \code
-    void backend::setFanSpeedLevel(int value, const QString &zone) {
+    void Backend::setFanSpeedLevel(int value, const QString &zone) {
         if (!m_fanSpeedZones.contains(zone)) {
             emit errorChanged(QIfAbstractFeature::InvalidZone);
         } else {
@@ -75,50 +76,10 @@ QT_BEGIN_NAMESPACE
             ...
             emit fanSpeedLevelChanged(value, zone);
         }
-   }
-
-    int backend::fanSpeedLevel(const QString &zone) {
-        if (!m_fanSpeedZones.contains(zone)) {
-            emit errorChanged(QIfAbstractFeature::InvalidZone);
-            return -1;
-        } else {
-            int value = ... // Get vehicle's zone fan Speed
-            return value;
-        }
-   }
+    }
     \endcode
 
-    Steering wheel heater is not zone specific, so zone attribute should be
-    empty. If zone is empty, the vehicle's actual steering wheel heater can
-    be controlled. The backend has to emit a signal for the changed value.
-    Because the attribute is generic, zone is omitted from the signal.
-    \code
-    void backend::setSteeringWheelHeater(int value, const QString &zone) {
-        if (!zone.isEmpty()) {  // zone must be empty for a generic attribute
-            emit errorChanged(QIfAbstractFeature::InvalidZone);
-            return;
-        } else {
-            // Set vehicle's steering wheel heater value
-            ...
-            emit steeringWheelHeaterChanged(value);
-        }
-   }
-
-    int backend::steeringWheelHeater(const QString &zone) {
-        if (!zone.isEmpty()) {  // zone must be empty for a generic attribute
-            emit errorChanged(QIfAbstractFeature::InvalidZone);
-            return -1;
-        } else {
-            int value = ... // Get vehicle's steering wheel heater value
-            return value;
-        }
-   }
-    \endcode
-
-    To implement a backend plugin you need also to implement QIfServiceInterface from the QtInterfaceFramework module.
-
-    See the full example backend implementation from \c {src/plugins/ifvehiclefunctions/climate_simulator}.
-    \sa QIfAbstractZonedFeature, QIfServiceInterface
+    \sa QIfAbstractZonedFeature
 */
 
 /*!
@@ -149,8 +110,8 @@ QIfZonedFeatureInterface::QIfZonedFeatureInterface(QObject *parent)
 
     Emitted when the available zones changed.
 
-    Use this signal when the list of available \a zones need to be retrieved first, and are not available
-    when the backend instance is created.
+    Use this signal when the list of available \a zones need to be retrieved first, and are not
+    available when the backend instance is created.
 
     \sa availableZones() {Providing Available Zones}
 */