This hides the explicit use of a QFormLayout from the aspect
interface in a new LayoutBuilder class. That currently works
only on a QFormLayout in the back, but opens the possibility
to use e.g. a QGridLayout as use on the Kits and some option
pages.
The aspects now only announce sub-widgets they like to add,
actuall positioning is does by a new LayoutBuilder class,
also cramming several widgets in an hbox in the right column
of the QFormLayout is done there.
Change-Id: I2b788192c465f2ab82261849d34e514697c5a491
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
In the new plugin setup scheme they are data members of the
plugin pimpl and never use the parent.
Change-Id: I28fe150393e8159064dcfbd113ce0320af50fd58
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Probably unused since the invention of buildKey().
Change-Id: I1bddd5f790e6dfdd509fd47bc5f5209cbaac091c
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This unifies the remaining paths of RunWorker creation to always
use RunWorkerFactories in the plugin pimpls.
There were, and are, still effectively three basic kinds of workers:
- "toplevel" tools corresponding to the run modes, that are often all
that's used for local runs and directly started via the fat buttons
or e.g. entries in the analyze menu, with factories already previously
located in the plugin pimpls
- core "tool helpers", providing tool specific functionality typically
used in conjunction with a remote device specific run mechanism,
set up via RunControl::registerWorkerCreator
- target/device specific runhelper like port gatherers contructed e.g.
via *Device::workerCreator(Core::Id id)
Worse, these categories are partially overlapping, so it was not
clear how a "clean" setup would look like, instead some ad-hoc cobbling
"to make it work" happened.
In some cases, the runMode id was used throughout the whole ensemble
of run workers for a given run, and which worker exactly was created
depended on which of the mechanism above was used in which order.
With the new central setup, the top-level runmodes remain, but the
second kind gets new ids, so the implicit dependencies on order
of setup mechanism are avoided.
This also helps in the cases where there was previously unclarity of where
and how to set up worker factories: It's always and only the plugin
pimpl now.
Change-Id: Icd9a08e2d53e19abe8b21fe546f469fae353a69f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This is what the consuming code expects in most cases.
Change-Id: I135592039e28b994996186f627215ab1d2f8d6dc
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
It is not even clear that the remaining difference are needed.
Change-Id: Ic4418143242793d82a1f4c4c368af69a2e537078
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... for build step related widgets. These are specifig to a build step
which in turn is only interested in its own build config and target.
Change-Id: I5ec277ba279932d18a615e528acffaccdc41e307
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Essentially following the scheme used for the various project
configurations. This makes it possible to construct OutputFormatters
by Id only, potentially reducing hard plugin dependencies and
opening the road to have several output formatters per
RunConfiguration/Outputpane/...
Change-Id: I4b5fb6fb6be8b0d9a0859f178bb0effc3398b09e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This combines two of the previous three paths to create run workers,
and refers to RunConfigurations by id, not by type where possible
to decrease coupling between the classes.
Only allow "type of run configuration" and "type of device"
as the only possible kind of restriction and require a uniform
RunWorker constructor signature.
Adapt user code to fit that pattern.
Change-Id: I5a6d49c9a144785fd0235d7586f244b56f67b366
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Xcode 11 changes the output of simctl slightly. At some point it
introduced a bool "isAvailable" in addition to the string
"availability". Now the latter has been removed.
To avoid listing all devices as available, we need to adapt our simctl
output parsing.
This already takes effect when installing Xcode 11 Beta, even when not
actually using it, since all Xcode versions share the simulator
infrastructure.
Fixes: QTCREATORBUG-22757
Change-Id: I1ef416f6c544db53d9ee99ccc3b0a2e97dfcc870
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... by a Project::buildConfigurationChanged. That's the only case
used, and saves filtering on the receiver side. Also, the passed
bc is (in non-null) the active one, so isActive checks are not
necessary.
The null case seems to be only possible to trigger when removing
the currently active build configuration manually i.e. happens rarely,
so having it trigger an unneeded final display update on the dying
build config is tolerable, so drop the null check in such cases
to achieve a more uniform pattern.
Change-Id: I46f72e9e277767214dbd6920dd86b026a7084f46
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Updating on changes to other build config seem excessive, as the
updated details only depend the owning build config.
Change-Id: Iba86f2b56033ac55381d452dd2a435e5dda72674
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Targets are different from {Run,Build,Deployment}Configurations,
both regarding the level in the ProjectExplorer hierarchy, and
also by the set of supported operations (e.g. aspects).
Change-Id: Ia8490e2280a9ecc518395c5e48ce2fd5d6d58fd2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The reasoning in 1b4766e26c did not take into account that the scope
of QT_NO_JAVA_STYLE_ITERATORS may change over time, as done with
f70905448f6 in Qt base.
Change-Id: Ib1966ff26c4d36d5f62e149d6b45baa4aecf825d
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... taking a QString for the executable.
This weakens the very explicit QString -> FileName conversion via the
named constructors for the special case of constructing a CommandLine.
I think that's worthwhile here, as it reduces the noise on the caller
site under circumstance where the nature of the thing is obvious.
Change-Id: I27b4a73639728893d053b2e7ba65cb745f0ffe83
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
For some reason, Q_UNUSED includes already a semicolon, adding one
on the user side creates an additional empty statement.
Change-Id: I9c5e8fac381345a60792cb75e2938fd53958d3b0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... over setting command and args individually.
Change-Id: Iec7c8d3a0b05fb8fa0639f7ddbe7ccdc7387d2a2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Plan is to only let the (base) factory create toolchains, having
the 'new' is a separate function complicates the process.
Change-Id: I1faff3e2ce4a19a2947ba4ac4e156ed56e5d18e5
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This is meant to be the only function directly creating tool chain
objects in the long run (and also the only one setting ids, removing
the need to spell them out in the individual constructors).
Change-Id: Idef242612a5a3f7012628b4080a03d6ee70e5ba0
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
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>
And realize that at most places (except native help viewer) the code
using them is not optional on macOS.
Change-Id: I308406a0e8f176dad4151d23a33cd3fc0fb8635c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Adds a cache entry "BUILD_PLUGIN_${NAME}", defaulting to ON which
can be set to OFF to disable building of a plugin.
Adds a extend_qtc_plugin function that should be used to add
properties to a plugin after add_qtc_plugin, instead of the
standard CMake functions target_... . The new function results
in a no-op if the plugin was disabled.
Change-Id: I57f6799620aea0aaa8b56acead4815ccced95911
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Introduced in 0c2101d816, but only started to cause problems since
555360c1d4.
Fixes: QTCREATORBUG-22449
Change-Id: Id531d7cb94c80b762f7981cf3414348080d0d613
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Based on Tobias Hunger's work from a few months ago.
The CMake configuration needs libclang and Qt paths specified as
CMAKE_PREFIX_PATH.
Auto tests are run with "ctest". At the moment the pass rate is 87%.
Change-Id: Iba98e39bf22077d52706dce6c85986be67a6eab0
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
For the command and the working directory.
Change-Id: Ia69dc7100aeb57bb6e1b35f4dd4f3cf3763d8cda
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
