... 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>
... via base project node functionality.
Change-Id: Ifd9c5b149e11c1d104abed200881fdfe93749144
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>
Instead of having the full class build-system dependent,
by relying on four more AndroidQtSupport functions for now.
Change-Id: I26842f3ec70b875ba4481ae36d8c85f86366cb88
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>
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>
Steps to reproduce the crash, start with the list a b a c, select the
second a and the c. Click on remove. The removeEntries will find that it
can remove two consecutive entries in one beginRemoveRows/endRemoveRows,
but will wrongly remove them starting at the first a.
The fix is too simply order the modelindexes in descendeding order such
that removing entries does not modify the rows.
Change-Id: I4be349f4bab8137075da0d8dfcef24f10dc25f92
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
Add a list view to the deployment settings which allows you
to add and remove libraries from the ANDROID_EXTRA_LIBS
variable in the .pro file.
Task-number: QTCREATORBUG-9849
Change-Id: Ic0131c46be8fdef4b226b5ceb0ee82ea4dd82c6a
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
