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>
QTBUG-28385 is biting us over and over (QWizard doesn't have close
button nor cancel button on Mac in Qt 5), and actually there's no reason
for us having a wizard without the features from Utils::Wizard.
Task-number: QTCREATORBUG-10346
Task-number: QTBUG-28385
Change-Id: I80c0d82fe6738496c2ac03c31a1c2757ade8e266
Reviewed-by: Jarek Kobus <jaroslaw.kobus@digia.com>
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
The AndroidManifest.xml is no longer needed in as many use cases as
before. So the new deployment does not automatically create a
android manifest. Offer a button on the deployment page to create
a android manifest. This also edits the .pro file adding the
ANDROID_PACKAGE_SOURCE_DIR.
Change-Id: I2655dd6c96e2087732b4d7240b31fe9fcf168600
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
