And de-argumentify a string that is easier to handle as two strings.
Change-Id: I1ba5d86ae870adb107dd5b0a70c6492f1cacafde
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Add the necessary contructor to TriStateAspect, too.
Change-Id: Ieb0f19cdf95f7492380d7c4e5663f455e4da3452
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
..when switching back to an older version of QC.
Amends e0219fad4d.
Change-Id: I3662eb95cf1ae72f92688f12cc15b7a42fb1452c
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
There are basically 3 states for the decision whether to start
a debugger or not. But these had been under-represented by just
displaying 2 states.
Enabled (checked) and disabled (unchecked) are obvious, but the
default of Auto (represented as checked) is there for convenience
of the user, but it has some drawbacks of failing its guess
whether to enable the debugger or not.
Turn the former check boxes into a tri-state combo boxes and
explicitly display the consequences inside the summary.
Task-number: QTCREATORBUG-28627
Change-Id: Ieffed5b227ae978555258097385d6e80dfad3ac6
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
By default QC performs an educated guess whether to enable
QML debugging or not.
Improve this as the detection may fail and leave the user without
a special hint depending on the project structure.
Fixes: QTCREATORBUG-28627
Change-Id: Ibd461aff2bf9be7058bdf33c8740ef07a457c365
Reviewed-by: hjk <hjk@qt.io>
Mainly in order to put the fields into a visual frame. By default
expanded.
Fixes: QTCREATORBUG-27151
Change-Id: I9920d2c9f3872860e75e938ea90a9165aee5b92f
Reviewed-by: hjk <hjk@qt.io>
Originally the idea was to only expose LayoutBuilder, but we
are getting more and more related items. Be consequent now,
and have everything in Utils::Layouting, but not in nested classes.
Change-Id: Ic0f98595882e5c60a25c30ec52df4a0ea79bc0ca
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Since we also license under GPL-3.0 WITH Qt-GPL-exception-1.0,
this applies only to a hypothetical newer version of GPL, that doesn't
exist yet. If such a version emerges, we can still decide to relicense...
While at it, replace (deprecated) GPL-3.0 with more explicit GPL-3.0-only
Change was done by running
find . -type f -exec perl -pi -e "s/LicenseRef-Qt-Commercial OR GPL-3.0\+ OR GPL-3.0 WITH Qt-GPL-exception-1.0/LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0/g" {} \;
Change-Id: I5097e6ce8d10233993ee30d7e25120e2659eb10b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
And instead of qgetenv.
Takes Qt Creator's setting at "Environment > System > Environment" into
account, which makes it easier on some platforms to set them (e.g.
macOS), can be configured differently in different settings paths, and
potentially can be changed at runtime (depending on usage).
Change-Id: I3ea7623fb528e13a202afa2f89b00e5ee83962d8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: David Schulz <david.schulz@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>
More explicit and more potential options (e.g. "treat grid as form")
than a bool.
Change-Id: I89413efe30410160c38b0e524ba64288dde2332e
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The aspects are now responsible for defining what data needs
to be copied and also to provide a suitable interface (kind
of source-compatible to direct use) for access.
The important change here is that RunControl::aspect(...) doesn't
need to access RunControl::runConfiguration() in fully aspectified
RunConfigurations anymore. In not-fully aspectified the runConfig
access is moved to the user code to make the problem visible there.
Long term, aspectification should be finished.
As an additional benefit, the resolving of macros etc can
now be done at the correct time.
Change-Id: I690d9f8f696ce9b4efd42082ba3f81b514efcb77
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
In most cases, the layout constructed in the builder was set
on a widget which in turn was put into a vbox in the actual
widget. This is not necessary, but needs some re-ordering.
Also make sure that using not-yet-parented widgets during
layout construction does not cause visible artifacts.
Change-Id: I75727a571da093d3131ea6fba467c2c646cdb6f1
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Classes involved are BaseAspect and some derived classes,
LayoutBuilder and VariableChooser.
This is mostly mechanical, with various include/using changes
to make it compile.
Change-Id: I624a457f3555f102e541c4c71e33a9423af32250
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
In most cases they are used directly, so there's not much Base* in that.
Added the old name as alias as porting help for a while.
Change-Id: I494a8a560b8996bcf74915ea3570b504df6a6b4c
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... and use it in the DebuggerRunConfigurationAspect.
Change-Id: I1079f1a307d5e4b286d32570c48299d296fa3061
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The differences in QFormLayout lead to unexpected results on macOS.
Change-Id: If2b55a6233af3f8ac1afa6e3c586a16a263b32b5
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
There should not be a need to have the linkQmlDebuggingLibrary Q_PROPERTY
anymore. The property is added for the benefit of the DebuggerAspect, which
can just check relevant BuildConfigurationAspect directly.
Change-Id: Ic47ca9e26911e096564fe77bd14bebe959b4f116
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... and make use of it in the qbs build configuration.
We cannot use it for qmake yet, because the build config there still has
a custom, non-aspectified widget.
Change-Id: Iacf902a2d9384d0074b10fdc98e082fa906fb6d6
Reviewed-by: hjk <hjk@qt.io>
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>
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>
None of the run configuration aspects that are added to each runconfig
depend on the actual runconfig, only two need the target, the rest
nothing at all. So use target as common denominator.
Change-Id: I31829e63ac79d5c707bb068d73fc6a4687cb4c47
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
... and adapt constructors to not take the now-unneeded
RunConfiguration pointer.
Change-Id: I53ff338f51334ff7b0c22d4bed92bfcfc8225ea7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
