Since we also license under GPL-3.0 WITH Qt-GPL-exception-1.0,
this applies only to a hypothetical newer version of GPL, that doesn't
exist yet. If such a version emerges, we can still decide to relicense...
While at it, replace (deprecated) GPL-3.0 with more explicit GPL-3.0-only
Change was done by running
find . -type f -exec perl -pi -e "s/LicenseRef-Qt-Commercial OR GPL-3.0\+ OR GPL-3.0 WITH Qt-GPL-exception-1.0/LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0/g" {} \;
Change-Id: I5097e6ce8d10233993ee30d7e25120e2659eb10b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The modification of gradle.properties files was originally a feature of
the Android plugin which eventually moved over to androiddeployqt.
Moreover, this code got accidentally disabled in Qt Creator 4.10 and was
appartently not missed till now. I only noticed it while "FilePath-
ifying" code in the Andsroid plugin.
This change removes the gradle.properties file handling code from Qt
Creator.
Fixes: QTCREATORBUG-28494
Change-Id: Id4f2722f4965c877a065386b34a71d8368147b08
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
... by a new PathChooser::textChanged signal.
They were both emitted in reaction to the underlying line edit's
textChanged() signal.
Use 'textChanged()' as name to mimic/match the Qt side. This also
makes it more clear on the user code side, when this happens.
Some textChanged() consumers should probably use editingFinished()
instead, but that's left for later changes.
Change-Id: Ib07347f616cbf1c5d09bc2f8671ca860d185d1f9
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Fix the wizard from inserting the filename for the file path leading to
an invalid directory.
Example invalid path: /projectpath/projectname/projectname.pro/android
With fixed path: /projectpath/projectname/android
Fixes: QTCREATORBUG-26580
Change-Id: If82a6f795ca400beddc26b959e65ea066ad79433
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
The the value was being set before the checkbox is connected, which
is useless.
Change-Id: Ifdbbccc1fe190e4dd646e77303af78757fadebb2
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
The Gradle files are usually not modified by the user, so it makes
sense to make the default behavior not to copy them, unless explicitly
set by the user.
Change-Id: I67a5a8ea402def55a65a4e98588c57a598c5f7d0
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Keep the old method for now to ease downstream porting.
The change is kept mechanical, there's a lot of cleanup possible now
on the user code side.
Change-Id: I936baedd45b7ba057f1c789a1bec896886f48eff
Reviewed-by: André Hartmann <aha_1980@gmx.de>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Instead of a Target and hoping that its activeBuildystem is the
right one.
Change-Id: Ieb384d89e8f580b24205ce46a38f151aa72e2f6e
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Qt 6 will not use qmake to identify a Qt version, so this can not
be part of the public interface of BaseQtVersion anymore.
Provide getters for the information actually read via qmakeProperty(...).
Use the getters whenever possible.
Change-Id: Iadbee80b75e4f8b06caf90e7ed69fae2029b4dd7
Reviewed-by: hjk <hjk@qt.io>
Previously, AndroidManager::updateGradleProperties operated always
on a project node found using target->activeRunConfiguration()
which might or might not be the one that will actually be used
after the build.
This here still does not address the problem that the activeRunConfiguration
may change but introduces a way to specify the relevant node, and tries
to use the right one when available.
At some time, this could be developed into a real solution, e.g.
by invalidating the cache on build key changes.
Change-Id: I37a3d73e9ad3615025e4def2493f683d11add3c6
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
More in line with QFileInfo terminonlogy which appears to be
best-of-breed within Qt.
Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Mainly to get rid of the QProcess::finished deprecation warning.
Also adjust coding style in the surrounding connects when needed.
Change-Id: I12f9b248c7974b892c4a069356e578e80f8c59e9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
A convenience wrapper for
applicationTargets().buildTargetInfo(buildKey),
the only context using the BuildTargetInfoList member.
Also, only one of the free comparison functions is ever used,
only in one place. Inline it there.
Change-Id: I7565e9d51d429af34352649e235243e5b3328fe9
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The name "KitInformation" does not properly convey the fact that it
represents a certain *aspect* of a kit. The same goes for
"KitConfigWidget", which in addition was inconsistent with
"KitInformation".
We now use "KitAspect" and "KitAspectWidget".
Change-Id: I9804ee4cedc4d61fad533ea1dd4e4720e67fde97
Reviewed-by: hjk <hjk@qt.io>
... from ProjectNode::targetData and setTargetData, and rename them
to data and setData.
It was only used in the implementation to retrieve the right node,
instead move the responsibility to find the right node to the caller.
Current assumption is that the functions were always called on
the right node already.
Change-Id: I9ae7e8a7ed5c79b924b99fd9a6a652bad56d114a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This uses the same approach as in the previous patches: Have some
generic interface in the base classes (here ProjectNode::targetData()
setTargetData()) and implement on the qmake project side.
Implementation for Cmake/QBS is architecture-wise possible, but
not used right now, and left for later.
Change-Id: I3bbf66170020cf9027a894cd66db15ec7ffbf499
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This makes it more similar to the classic QAbstractItemModel::{data/setData}
pattern and hides qmake-specific semantic (variables are QString*Lists*)
behind something more general.
Change-Id: I82d7006affd4af208be2b7640076698d13fd3a61
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
- Split up androiddeployqt into two steps: One building the apk,
and one deploying it to the device.
- The build apk step base class AndroidBuildApkStep is ihneritaged by
the qmake specific class QmakeAndroidBuildApkStep.
- The deployment step is still called androiddeployqt
- Move all qmake specific code to the qmakeprojectmanager plguin
- Flip the depencency between the android and qmake plugin, now
the qmake plugin depends on the android plugin, implementing
a interface the android plugin provides.
- Note: This removes the debug deployment for now.
Change-Id: I1c386640159ed14b637668abde8eb3b9009ab803
Reviewed-by: BogDan Vatra <bogdan@kde.org>
There are multiple copies of these pngs in different plugins.
Let's have one version in core, also as @2x variant.
Change-Id: Iedff1a6190a72c1947dd202ae1ee46f59f9fb13c
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Reviewed-by: Alessandro Portale <alessandro.portale@digia.com>
Instead of repeating strings like
":/projectexplorer/images/compile_warning.png" all over the code,
we should use constants for it.
Change-Id: I91b36838d6da0a2332381e433788e796948d26db
Reviewed-by: hjk <hjk121@nokiamail.com>
The workflow for adding a library for multiple archs is not ideal, but
now a little better. The user has to go to the deploy setting for a
kit per architecture and add the right extra library.
Change-Id: I2bda6961f6f1164bdc58acd78fa3d2221977f0cf
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
On creating a AndroidManifest.xml we ask the user where to put the file,
which as a sideeffect also sets ANDROID_PACKAGE_DIR.
Since we copy everthing from ANDROID_PACKAGE_SOURCE_DIR into the build
directory, using the project's source directory is not desireable.
We now show a big error if the user tries that.
Task-number: QTCREATORBUG-11708
Change-Id: I7fade3efac0b7466cad8e83a92c2115d0a70c683
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
