doc: Remove the Extending Qt Interface Framework page

The page was outdated and just repeated what's already explained
in other places.

Fixes: QTBUG-99001
Change-Id: Iffa865665a9fe07b005a64b68b18f7fd64fff75e
Reviewed-by: Robert Griebl <robert.griebl@qt.io>

4 files changed, 2 insertions, 111 deletions

diff --git a/src/interfaceframework/doc/src/extending-qtif.qdoc b/src/interfaceframework/doc/src/extending-qtif.qdoc
deleted file mode 100644
index bca6d955..00000000
--- a/src/interfaceframework/doc/src/extending-qtif.qdoc
+++ /dev/null
@@ -1,108 +0,0 @@
-// Copyright (C) 2021 The Qt Company Ltd.
-// Copyright (C) 2019 Luxoft Sweden AB
-// Copyright (C) 2018 Pelagicore AG
-// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only
-/*!
-\page extending-interfaceframework.html
-\title Extending Qt Interface Framework
-
-\section1 Introduction
-
-Qt Interface Framework provides a pattern for extending Qt with more features
-in a way that suites the automotive use-case.
-
-A key aspect is the separation between the front end that defines the API, from the
-back end that implements the functionality. This separation makes it possible to have
-multiple implementations of the same API which can be used to interface various hardware
-configurations, but also to provide stubbed or simulated implementations for early
-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 service or to a
-simulation of it.
-
-\section2 Features
-
-A feature is a set of classes for working with a specific function. It defines the interface
-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.
-
-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 qdoc and auto test.
-
-\code
-make tests
-\endcode
-
-When creating a new Qt Interface Framework module, it is recommended that you pick a name such as
-\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}
-
-Features are based on the QIfAbstractFeature base class, or QIfAbstractZonedFeature for
-zoned features. These classes provide the basic functions expected by users, e.g. back end
-loading.
-
-Features define the back-end interface to be implemented by the back ends providing the
-functionality. The back-end interface is commonly based on the QObject class. It is important
-to keep this API as unbiased as possible, as there might be multiple back-end implementations
-relying on different technological solutions.
-
-Some key rules to keep in mind are:
-
-\list
-\li Keep everything asynchronous to avoid blocking the main loop.
-\li Avoid call-to-signal sequences and try to keep signals independent from calls, For example,
-when a value change is signaled, it must not be due to a call to change the value from
-the feature (and visa versa). In other words a call to change a value is not required to always
-result in a value changed signal.
-\li Implement stateless APIs whenever possible as the back end may be replaced at any time.
-\endlist
-
-It is common to provide a stubbed back-end implementation and a testing back end with each
-feature.
-
-\section2 Back ends
-
-A back-end class is derived from the (commonly QObject-derived) back-end interface
-class specified by a feature. Instances of the back-end class are called \e {service objects}.
-
-Back ends are implemented as an ordinary Qt C++ plugin project that depends on
-\l {QtInterfaceFramework}{Qt Interface Framework Core} and the corresponding feature module.
-
-The back ends are loaded by Qt Interface Framework Core when the features request them.
-Each back end has to provide a Qt Interface Framework plugin that exposes a \e factory to the Core.
-This is what is used to load and create back ends. The plugin interface is called QIfServiceInterface.
-
-\section2 Service Manager
-
-In most cases, the back-end loading is handed over to the Qt Interface Framework Core.
-In some cases QIfServiceManager can manually search for plugins with a specific
-BackendInterface. The discovery and loading of the back ends takes place in this class.
-
-The QIfServiceManager class can also be used to register back ends which are part
-of the same application and shouldn’t go into a plugin. This is especially useful
-for automated testing as you need to control the back end and the feature at the same time.
-
-\section1 Common Practices
-
-The reference APIs provided as a part of Qt Interface Framework introduce some common concepts. If
-implementing the same functionality, it is recommended to use these already defined patterns and
-it is encouraged to add API additions back to the Qt Interface Framework repository to create more common ground
-for future APIs.
-
-*/
diff --git a/src/interfaceframework/doc/src/qtif.qdoc b/src/interfaceframework/doc/src/qtif.qdoc
index 3230b73d..55a6bc3e 100644
--- a/src/interfaceframework/doc/src/qtif.qdoc
+++ b/src/interfaceframework/doc/src/qtif.qdoc
@@ -72,7 +72,6 @@
        \li \l{Concepts and Architecture}
        \li \l{Get Started with the Qt Interface Framework Generator}
        \li \l{Qt Interface Framework Generator Tutorial}
-       \li \l{Extending Qt Interface Framework}
        \li \l{What's New in the Qt Interface Framework}
     \endlist
 
diff --git a/src/interfaceframework/qifabstractfeature.cpp b/src/interfaceframework/qifabstractfeature.cpp
index 9968ae24..603a922f 100644
--- a/src/interfaceframework/qifabstractfeature.cpp
+++ b/src/interfaceframework/qifabstractfeature.cpp
@@ -380,7 +380,7 @@ void QIfAbstractFeature::componentComplete()
     When the feature discovers a matching backend, this interface's name needs to be supported by
     the service object that the feature is connecting to.
 
-    See \l {Extending Qt Interface Framework} for more information.
+    \sa acceptServiceObject
 */
 QString QIfAbstractFeature::interfaceName() const
 {
diff --git a/src/interfaceframework/qifabstractfeaturelistmodel.cpp b/src/interfaceframework/qifabstractfeaturelistmodel.cpp
index ed439480..2cdb8699 100644
--- a/src/interfaceframework/qifabstractfeaturelistmodel.cpp
+++ b/src/interfaceframework/qifabstractfeaturelistmodel.cpp
@@ -581,7 +581,7 @@ void QIfAbstractFeatureListModel::componentComplete()
 /*!
     Returns the interface name this Feature expect to be available from the Service Object and this Feature is implementing.
 
-    See \l {Extending Qt Interface Framework} for more information.
+    \sa acceptServiceObject
 */
 QString QIfAbstractFeatureListModel::interfaceName() const
 {