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>

We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.

Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace.

Task-number: QTBUG-99313
Change-Id: I601bf70f020f511019ed28731ba53b14b765dbf0
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>

Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.

Pick-to: 6.4
Task-number: QTBUG-67283
Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>

The original attempt, deb238586a "QQuickIcon: Resolve URL relative to
current element," works fine for IconLabel itself, but not for Buttons
containing IconLabel.

  // <style>/Button.qml
  T.Button {
      id: control
      icon:  // owner: control
      contentItem: IconLabel {
          icon: control.icon  // owner: this, but should be control
      }
  }

  // user code
  Button { icon.source: "a.png" }

Since IconLabel is an implementation detail of the Button, IconLabel.icon
owner needs to point to the Button so the user-specified icon.source can
be resolved relative to the user code, not to the <style>/ directory.

This patch fixes the problem by explicitly resolving the source URL on
setIcon() and propagating the resolved icon object to the inner items.
If the relative URL has already been resolved by e.g. Button, the inner
IconLabel never resolves the URL again to itself.

The problem could be addressed by initializing icon owner only once by
Action/Button constructor, but that would lead to dangling owner pointer
as icon object could be copied anywhere. So I've added resolvedSource
data member in place of the owner pointer.

  Button { id: dangling }
  Button { id: victim; icon: dangling.icon }  // owner: dangling
  Component.onCompleted: dangling.destroy()
  // ... would SEGV (or use after free) if victim.icon.source modified.

Fixes: QTBUG-95587
Pick-to: 6.2 6.3
Change-Id: Ibdd07118e79f1e1f36e1faea0289150eca734e27
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>

Remove usages of outdated LGPL3 header that references LICENSES.LGPLv3
instead of LICENSES.LGPL3.

Change-Id: If7a90ec18331a68491c5a740f131a5e7b3f37df4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>

If the entry for the QQuickItem that the QQuickAction is set on has
already grabbed the shortcut, then m_shortcutId is no longer 0 and we
must not overwrite the value. Otherwise, the QQuickItem removing itself
from the action might not remove the correct entry from Qt's shortcut
map, leaving a dangling pointer behind.

Multiple calls to QQuickActionPrivate::ShortcutEntry::grab are possible,
because we grab the shortcut whenever the shortcut changes, or when an
item representing the action becomes visible.

The test case added reproduces this scenario by adding the action to a
menu item and then making the menu explicitly visible, resulting in two
calls to grab() which should be idempotent.

Fixes: QTBUG-96551
Fixes: QTBUG-96561
Pick-to: 6.2
Change-Id: I7d42a4f4c04f7d8759f2d0f24a133720f10e4c47
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Jarkko Koivikko <jarkko.koivikko@code-q.fi>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>

If a user passes a relative URL to icon, they probably expect the URL to
be handled relative to the current file (like in Qt 5). We restore this
behavior by doing the URL resolution in the current QML context.
Unfortunately, as a gadget, QQuickIcon does not have its own context.
Thus, we need to store (and set) a pointer to its "owner", so that we can
retrieve the context for the binding that causes the URL to be set.
We adjust the three classes which currently use QQuickIcon to set the
owner in their setIcon methods.

Task-number: QTBUG-95587
Pick-to: 6.2
Change-Id: Icd1f2ddf65ae7d09ff787a50a01f1db78c571abf
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>

This is apparently no longer necessary.

Pick-to: 5.15
Change-Id: I0f45a84ced5118d248ffab4e745c4e2f2ce5738f
Reviewed-by: Paul Wicking <paul.wicking@qt.io>

Change-Id: I4e6c1b03915c33f6225c0fb7f86e6acb7715cd4d
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>

This was missed in 033564edf5b79e32da63597930e25105a3442f01.

Pick-to: 5.15
Change-Id: I7bc465338d5b9960ad7b746a816cd33efcca1bdc
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>