This move the subWidget title a bit closer to its content in order to
render their relation more visible.
Change-Id: I8cb8e7967db05021a20007dc4165f132b2213326
Reviewed-by: hjk <hjk@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>
If the original configuration is not a shadow build, there is no reason to
generate a new directory name when cloning the configuration.
Change-Id: Ie84ee01ac70c69161e65a0b58cdfbfbe1a1630ab
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... after cloning a build configuration.
It's very unlikely that the user intends to re-use the same build
directory in the new build configuration.
Fixes: QTCREATORBUG-24831
Change-Id: I39b7839225e973fea4e16b9b686fbbf9207cb5ae
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
There are very few reasons to use mainWindow() directly.
Especially for modal dialogs, using dialogParent() is important, since
that guarantees the stacking order in case of other dialogs currently
being open.
Change-Id: I7ad2c23c5034b43195eb35cfe405932a7ea003e6
Reviewed-by: hjk <hjk@qt.io>
... or Target.
This patch moves build system from conceptually "one per project"
to "one per target (i.e. per project-and-kit)" or "per
BuildConfigurations" for targets where the builds differ
significantly.
Building requires usually items from the kit (Qt version, compiler,
...) so a target-agnostic build is practically almost always wrong.
Moving the build system to the target also has the potential
to solve issues caused by switching targets while parsing, that
used Project::activeTarget() regularly, with potentially different
results before and after the switch.
This patch might create performance/size regressions when several
targets are set up per project as the build system implementation's
internal data are duplicated in this case.
The idea is to fix that by sharing per-project pieces again in
the project implementation once these problems occur.
Change-Id: I87f640ce418b93175b5029124eaa55f3b8721dca
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This kind of two-phase setup is not needed here.
Change-Id: Ie070c711ede1e4842f76f7d4ebf26809a3ad5236
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It's a widget containing a single widget with zero margin.
Use the inner BuildStepListWidget directly.
Change-Id: Ib2e6d63d4dbc570f45e287b216e0a9cfd5c5b8a1
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The models hold essentially duplicated information besides the actual
configuration lists that are already in the target and are only
used in a context where the target is known and accessible.
As the models keep track of all added or removed configurations
and can be fed configurations of the right types only, the need
to filter is gone.
Change-Id: Iec2c6879223893297c71e7632310ac526b704237
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>
... to pass it around as real values, avoiding, among others,
the need of occasional explicit deletion.
The formerly extra members of the derived stuff are handled via
an extra variant (for data) and via a functor in the build
configuration factory.
The change is mechanical.
Change-Id: I19ca4e0c5f0a5b196fc16dfb98bb005dc679f855
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... to BuildConfigurationFactory. It hasn't been an Interface for a
while and the new name matches Run- and DeployConfigurationFactory
Change-Id: I923c6a27e18a99628251b69e0270e910836e7b2a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Cloning, just like removing and renaming, is an action on an existing
build or run configuration and should be presented in the same way,
instead of being the odd one out in the list of possible run
configurations that pop up when clicking the "Add" button.
Change-Id: I2574cf27d013dce9c52852014a393f211f9c3799
Reviewed-by: hjk <hjk@qt.io>
This is far from perfect but seems to work. Further work could add more
fine grained control over which projects are affected by the automatic
synchronize. Also there might be a few cases where the switching is
over zealous or missing.
Change-Id: I26ad3d59431251564917e4b408c66695dc454823
Task-number: QTCREATORBUG-5823
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Do not allow to rename buildconfigurations if there are none.
Change-Id: I3da2ea9568c2dabf555685c3b27192bea8dcc009
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
BuildSettingsWidget::createConfiguration() works with a BuildInfo
object borrowed from an IBuildConfigurationFactory, and uses it to create
a new build configuration.
The original BuildInfo object should not be permanently changed, as it's
only used here for creating the new build configuration.
Ideally, it should work on a clone of the buildinfo/factory, but that
would require adding and implementing a polymorphic clone method
for either class.
This commit works around this problem by restoring the original
displayName of the buildinfo after use.
Task-number: QTCREATORBUG-12955
Change-Id: Iccf2123c4377a39396860a1cfaa817a98dacebd4
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
The indirection via a factory is no longer useful, since the
targetsettingspanel is hardcoded for a build and run panel.
Change-Id: I75543f777a4a7df4cadf12667652424056829689
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
This was the common base class of IProjectPanelFactory and
ITargetPanelFactory. Nothing was using the IPanelFactory interface, and
there's actually no common interface between those classes.
Of the old interface IPanelFactory:
id() => only used in ITargetPanelFactory
displayName() => only used in IProjectPanelFactory
priority() => only used in IProjectPanelFactory
This removes lots of boiler plate code for the unused functions.
Change-Id: I8488a4e5134fd451907f02c45b7847673e4dc714
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Generalize the target setup page and move it into projectexplorer
Move the qmake specific code into a projectimporter class with
a specialization for qmake projects in the qt4projectmanager.
This change depends heavily on the BuildConfigurationFactory cleanups
done earlier and completes that change in such a way that generic
build configuration factories are now in theory possible. The
remaining problem is how to select the best factory of several that
claim to be able to handle a kit and that is left for the next patch.
Change-Id: I47134cb1938c52adebcdc1ddfe8dbf26abbbbeee
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Refactor the code of the build configuration factories. The idea is to
generalize the code so much that we can allow plugins to install
custom build configuration factories for the platforms they support.
To support this use case the following changes where done here:
* BuildInfo class was introduced to describe one build configuration that
can be created by a factory.
* Factories report a list of BuildInfo to describe what they can produce.
This fixes the need for factories to implicitly create one buildconfiguration
and then create another one 'officially' to support debug and release build
configurations to be set up for projects.
* Do no longer work around factories to create build configurations.
Change-Id: Ic372e4a9b5c582633b467d130538948472b89d91
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Currently the BuildConfigWidgets are created once and init(bc) is
called on switching BuildConfigurations. That's odd since the
createCongigWidget() function is on the BuildConfiguration and not
the project. Recreating the widgets on switching bcs does introduce
some flickering and collapses the BuildEnvironmentWidget, but that's
a minor regression.
Change-Id: I0672655c8796741fc5ddaba9768817fe2951c335
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Indicating that new widgets are indeed created.
Change-Id: Iccc5e1e99f536fdfb0718f252a23f498053ad3a3
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
* Rename profiles to kits.
* Update some strings:
* projects mode has a Kits tab, not a Targets tab.
* " Settings" was dropped from the sub-tabs of the Kits tab
* menu entry "Build/Open Build/Run Target Selector" was renamed
to "Build/Open Build and Run Kits Selector".
* Use "Kit" instead of "Target" in miniprojecttargetselector.
(The class was not renamed as it does indeed select targets,
not kits)
Change-Id: I0727e086e2dfa0e8aaaf89fdc6f2e3596c7a4314
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
