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>
