Doc: Adding overview docs

Added overview documents introducing the big picture, concepts and guidelines for using and extending Qt IVI.

Task-number: QTAUTO-58
Change-Id: I29fba4a8e8c492b5dcb78ef66363628600a1a2b7
Reviewed-by: Robert Griebl <robert.griebl@pelagicore.com>

1 files changed, 2 insertions, 191 deletions

diff --git a/src/ivicore/doc/src/qtivicore.qdoc b/src/ivicore/doc/src/qtivicore.qdoc
index d41a80e..432ed5d 100644
--- a/src/ivicore/doc/src/qtivicore.qdoc
+++ b/src/ivicore/doc/src/qtivicore.qdoc
@@ -34,197 +34,9 @@
 
     \brief C++ classes for the Qt IVI Core API.
 
-    Qt IVI provides a pattern for extending Qt with extendable APIs. It also comes with a set of
-    demonstrator APIs that can be used as a starting point or off-the-shelf in your projects.
+    The Qt IVI Core C++ API provides core functions for in-vehicle infotainment C++ types.
 
-    The pattern is based around separation of the API facing the application developer, the so
-    called \e {Feature}, and the code implementing it, the \e {Backend}. There can be multiple
-    backends per feature and the Core module provides support for finding the corresponding
-    backend in an easy-to-use way.
-
-    Common use cases driving this separation are:
-
-    \list
-    \li \e {Early development}, where the UI can rely on a feature with a very basic backend
-        implementation.
-    \li \e {Testing / Simulation}, where the backends can be tested separately from the app and the
-        app can be tested using a specialized testing backend.
-    \li \e {Targets with different hardware configurations}, where certain parts of the system are
-        represented by simulated backends while others use a real hardware integration.
-    \li \e {Dynamically appearing services}, when services are available sometimes, but not always,
-        meaning that backends come and go over time.
-    \endlist
-
-    \section1 Building Blocks
-
-    Qt IVI consists of a number of building blocks. Understanding the roles of these is key to using
-    Qt IVI.
-
-    \section2 Core
-
-    The core module provides base classes for writing features and backends as well as the
-    mechanisms for finding the correct backend for each feature.
-
-    The core also contains common classes and base classes for various models and shared types.
-
-    \section2 Feature
-
-    The feature is what an application developer uses. The feature contains the API facing the
-    applications, but also the backend interface, i.e. the interface that the corresponding backend
-    needs to implement. The object implementing the backend interface is called as service object.
-
-    The backend interface defines an interface name. This is a unique string identifying the
-    interface between the feature and the backend. It is commonly written using reverse domain name
-    notation, e.g. com.example.FeatureName. This is what is used by Core to find service objects
-    for a feature.
-
-    The feature is derived from the QIviAbstractFeature class. The backend interface is commonly
-    based on QObject.
-
-    To make the API useable from QML, the feature needs to include a QML plugin registering types
-    and classes. The QML plugin is derived from the QQmlExtensionPlugin class.
-
-    It is common to include a simple stubbed backend and a testing backend with each feature.
-
-    \section2 Backend
-
-    A backend implements the backend interface specified by the feature. The backend is derived from
-    the backend interface class defined by the feature, which is a QObject derived class.
-
-    The object implementing the backend is called as service object.
-
-    The backends are loaded by Core when the features request them. Each backend has to provide a Qt
-    IVI plugin that exposes a factory to the Core. This is what is used to load and create backends.
-    The plugin interface is called QIviServiceInterface.
-
-    \section2 Simple vs Dynamic Features
-
-    Most features are simple. This means that each feature element needs a single service object. By
-    setting the autoDiscover property of QIviAbstractFeature to true, the Core module provides the
-    first compatible service object to the feature and issues a warning if none or more than one
-    compatible service object is found.
-
-    When auto discovery is used, Core looks for the backend once during the creation of the feature
-    instance. When used from QML, this takes place when the feature element is completely
-    initialized. From C++, it is made when a call to the startAutoDiscovery method is called.
-
-    For dynamic features, there can be multiple service objects for each feature. This means that
-    the auto discovery mechanism does not work. Instead the application must take responsibility for
-    finding the right service object for each feature instance.
-
-    QIviServiceManager can be used in this case to manually search for plugins with a specific
-    BackendInterface. The discovery and loading of the backends takes place in this class.
-
-    The QIviServiceManager class can also be used to register backends which are part of the same
-    application and shouldn’t go into a plugin. This is especially useful for autotest as you need
-    to control the backend and the feature at the same time.
-
-    \section1 Extending Qt IVI
-
-    For easy deployment, Qt IVI 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:
-
-    \code
-    QT += <module>
-    \endcode
-
-    In addition, your module is properly set up to work with cmake, qdoc, and auto test."
-
-    \code
-    make tests
-    \endcode
-
-    When creating a new Qt IVI 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 {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 backend interface names, for example \e {com.example}.
-
-    Notice that it is possible to have multiple feature element classes in a single module. For
-    instance, the media module of Qt IVI contains both source discovery, media search, and media
-    browse APIs.
-
-    Having decided on a name and a backend interface name prefix, the template module can be checked
-    out from git. Then the renamer script is used to create the module, for example:
-
-    \code
-    ./renamer.sh Oem MyFeature com.pelagicore
-    \endcode
-
-    This will result in the \e {OemMyFeature} module to be created and the backend interfaces
-    prefixed with \e {com.pelagicore}, e.g. \e {com.pelagicore.MyFeature}.
-
-    The resulting directory structure is described in the table below.
-
-    \table
-    \header
-      \li Path
-      \li Description
-    \row
-      \li \c {examples}
-      \li Examples top-level directory
-    \row
-      \li \c {examples/feature}
-      \li Feature specific example directory
-    \row
-      \li \c {example/feature/feature_qml}
-      \li Template QML-based feature example
-    \row
-      \li \c {example/feature/feature_widgets}
-      \li Template widgets-based feature example
-    \row
-      \li \c {src}
-      \li Source code top-level directory
-    \row
-      \li \c {src/feature}
-      \li Feature source code. Includes feature APIs as well as backend interfaces
-    \row
-      \li \c {src/feature/doc}
-      \li Feature documentation configuration
-    \row
-      \li \c {src/imports}
-      \li QML import modules top-level directory
-    \row
-      \li \c {src/imports/feature}
-      \li Template feature QML import module
-    \row
-      \li \c {src/plugins}
-      \li Qt IVI backend plugins directory
-    \row
-      \li \c {src/plugins/feature}
-      \li Feature Qt IVI backends directory
-    \row
-      \li \c {src/plugin/feature/feature_stub}
-      \li Stubbed template feature Qt IVI backend
-    \row
-      \li \c {tests}
-      \li Unit tests top-level directory
-    \row
-      \li \c {tests/auto}
-      \li Automatic tests directory
-    \row
-      \li \c {tests/auto/feature}
-      \li Template feature unit test
-    \row
-      \li \c {sync.profile}
-      \li Qt module control script
-    \endtable
-
-    To add more feature APIs, simply add them into \c {src/feature} and
-    \c {src/imports/feature}. To add more backends, add them to \c {src/plugins/feature}.
-
-    If another OEM specific feature is needed there is no need to create the whole folder structure
-    again. Simply add your feature’s code into the example \c {src} and \c {tests} folders and add
-    it to the \c {sync.profile} file.
-
-    To create a backend for an existing feature, simply create a new Qt project based on the feature
-    module in question and build a Qt IVI backend plugin.
-
-    \section1 Creating a Qt Module
-    \section1 Creating a Feature
-    \section1 Creating a Backend
+\section1 C++ Classes
 */
 
 /*!
@@ -239,4 +51,3 @@
 
     \section1 QML Types
 */
-