Remove "2" from Qt Quick Controls directories

Qt Quick Controls 2 was named that way because it was a follow-up to
Qt Quick Controls 1.x. Now that Qt Quick Controls 1 is no longer
supported, we don't need to have "2" in the name. Work on this was
already started for the documentation in
1abdfe5d5a052f2298b7bf657513dfa7e0c66a56.

By doing this renaming a few weeks before feature freeze, it won't
affect the release but still results in as little time possible spent
manually fixing conflicts in cherry-picks from non-LTS releases as a
result of the renaming.

This patch does the following:

- Renames directories.
- Adapts CMakeLists.txt and other files to account for the new paths.

A follow-up patch will handle documentation.

It does not touch library names or other user-facing stuff, as that
will have to be done in Qt 7.

Task-number: QTBUG-95413
Change-Id: I170d8db19033ee71e495ff0c5c1a517a41ed7634
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>

1 files changed, 73 insertions, 0 deletions

diff --git a/src/quickcontrols/doc/src/qtquickcontrols2-deployment.qdoc b/src/quickcontrols/doc/src/qtquickcontrols2-deployment.qdoc
new file mode 100644
index 0000000000..daea9eccf0
--- /dev/null
+++ b/src/quickcontrols/doc/src/qtquickcontrols2-deployment.qdoc
@@ -0,0 +1,73 @@
+// Copyright (C) 2017 The Qt Company Ltd.
+// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GFDL-1.3-no-invariants-only
+
+/*!
+    \page qtquickcontrols2-deployment.html
+    \title Deploying Qt Quick Controls Applications
+
+    Deployment of Qt Quick Controls applications is very similar to
+    deployment of other types of Qt applications. However, there are a few
+    factors to consider.
+
+    \section1 Deploying an Application with Several Styles
+
+    Suppose you have an application that will be deployed to both Android and
+    Windows devices. To ensure that only the minimum set of files that are
+    necessary for the application to run are deployed to each device, you can
+    use file selectors. For example, your directory structure could look like
+    this:
+
+    \code
+    resources.qrc
+    main.qml
+    +windows/MyPage.qml
+    +windows/qtquickcontrols2.conf
+    +android/MyPage.qml
+    +android/qtquickcontrols2.conf
+    \endcode
+
+    In the project above, \c main.qml would import \c QtQuick.Controls, for
+    example, but shouldn't import, say, \c QtQuick.Controls.Material. Any code
+    that is style-specific is moved out into separate files; just as we've done
+    for \c MyPage.qml.
+
+    The \c +windows/qtquickcontrols2.conf file would contain configuration
+    options specific to the Universal style:
+
+    \code
+    [Controls]
+    Style=Universal
+
+    [Universal]
+    Theme=Dark
+    Accent=Red
+    \endcode
+
+    The \c +android/qtquickcontrols2.conf file would contain configuration
+    options specific to the Material style:
+
+    \code
+    [Controls]
+    Style=Material
+
+    [Material]
+    Theme=Light
+    Accent=Brown
+    \endcode
+
+    \section1 Static Builds
+
+    For dynamically built applications, it is not necessary to import a
+    specific style that should be usable by that application. For statically
+    built applications, Qt's build system must be involved to ensure that
+    QML plugins function as expected. Specifically, \c qmake uses
+    \c qmlimportscanner to scan the QML files in your application for import
+    statements. For this reason, any styles that should be usable by a
+    statically built application must explicitly import that style. Where the
+    import occurs is up to the developer, but it is recommended to follow the
+    approach mentioned in the \l {Deploying an Application with Several Styles}
+    section, so that only the minimum set of files that are necessary for a
+    particular device are deployed.
+
+    \sa {Deploying Qt Applications}, {Using Styles in Qt Quick Controls}
+*/