According to https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews
QSharedPointer impl is poor and it's going to be removed from Qt 7.
Replace QWeakPointer with std::weak_ptr.
Replace QEnableSharedFromThis with std::enable_shared_from_this.
Use std::static_pointer_cast and std::dynamic_pointer_cast
for casts used with QSharedPointer before.
Change-Id: If255a100c790860934f36d52906b93f33c31cfe8
Reviewed-by: hjk <hjk@qt.io>
We currently cannot support anything than running for devices with iOS
17 and later.
Make it possible for RunConfigurations to state that they are disabled
depending on run mode.
Change-Id: I13df4dd482f6381cda15168c38ede00d95e1d692
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The iOS Simulator device is always there, and always usable, it never
can be unavailable. Since now the device state leads to a decoration in
the device selector(s), always having a "connected" bubble there looks
confusing. Remove it.
Change-Id: Ia218e05367a18841e966ea8566e16ad859a09597
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
These are functional replacements for
QVariant::fromValue(QVariantMap) (or QVariant::fromValue(Store)) and
QVariant::toMap() (or QVariant::toValue<Store>())
We will have a few code paths in the end that need to explicitly
operarate on both QVariantMap and Store (e.g. actual reading/writing
to keep format compatibility etc), so these can't in the end be
simple to/fromValue(OneType) but need an internal 'if' or such.
Change-Id: I954f3cb24fa8fe123162b72bbd25d891dd19b768
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
After this one, is compiles with the opt-in macro. Not changed yet,
though.
Change-Id: I29a66ecb5daa71d0d97566b81fd9f47d92f6368a
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Follows suite to 2cc4967 to have the user side code more uniform.
Most of the extra verbosity (setMacroExpander) can go away again
when distributing the expander via the "owning" AspectContainer.
Change-Id: I9e80cb235f0a4a9ebee601dd638aefbaa41efc1b
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
... by an (only) slightly less weird setter.
Helps with a more uniform aspect API.
Task-number: QTCREATORBUG-29168
Change-Id: I40d2e878987ed7b817e08d250566bc548712749d
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
LayoutBuilder is meant to be an implementation detail nowadays.
Change-Id: I777ab934d3d405873e819eeddd27428d8c652f9a
Reviewed-by: Alessandro Portale <alessandro.portale@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>
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>
Just run and host is not enough, build device is needed, too.
This fixes the MakeInstall step for remote linux.
Change-Id: I3ec797379b7d0d5842780d505d8b87a91286e460
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
In the past we wanted to keep the aspect constructor simple but
it turned out that exceptions were needed and accumulating, so those
are likely here to stay.
By passing also the MacroExpander to the ArgumentsAspect constructor
allows other single-purpose warts like the ProjectConfiguration::doPostInit()
machinery can be removed.
Change-Id: I148b0ca1ab0740270eecd0d3134620de65a86d4f
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
The data is now pulled out of the runconfig directly instead of relying
on the indirection using the runconfig pointer inside RunControl.
This is only barely better, but gets rid of one direct user of
RunControl::runConfiguration().
Change-Id: If93576ba25ea9f3ddbeae2535217f5c2f361eaf6
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Improve support for running iOS bundle built with CMake introduced in
3a294f670d.
Currently it supports only Xcode generator and does not work if target is
created in a subdirectory.
This patch adds support for non-Xcode generators (tested with Ninja) and
targets created in a subdirectories with any generators.
The solution is not pretty due to the need to keep qmake compatibility.
Would be glad to refactor if there's more correct approach.
Change-Id: Ieaf7e3186ab55cadc643d9bd3d94442f9ac72228
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
- the var args template for addItems was overkill creating a lot of
instantiations. Use a temporary list instead.
- allow default constructed LayoutItems to be used for an empty cell,
avoiding the use of a QLabel with empty text
- add an addRow({...}) overload as convenience shortcut for
.startNewRow().addItems({...}
- rename startNewRow() to finishRow()
Change-Id: I6d49dacbac3d7acf140ca526884ba1ceeeca2e0d
Reviewed-by: Eike Ziller <eike.ziller@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>
For convenience, and use it in some places.
Change-Id: I8f7cb502b37b2fbf4cf2d17cac9c6299558332dc
Reviewed-by: Christian Kandeler <christian.kandeler@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>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Including some random uses.
This mimics std::filesystem::operator/(std::filesystem::path).
Change-Id: I0b0f5cf0d962fd33d4cbb9be96645a0b4a21ee03
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... by an explicit update() call. This is what effectively done in
most cases, and should be harmless and reasonably cheap in most other
cases.
Change-Id: I323112ec7cdbccf19050ac54466d8e1d97a0516e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
While triggering unncessarily in some cases now, the function
is cheap and moving the call out of the way will allow for
removing RunConfiguration::doAdditionalSetup() later.
Change-Id: I06961ca43e6e56ebd16bf3c04e8ce0a4478494ba
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
RunConfiguration::update() is becoming a central place acting on
requests to act on interesting changes, triggering notifications
to "the outside" from there is natural.
Change-Id: I159cb548c159a607e2628a178362987fb37b59e3
Reviewed-by: Christian Kandeler <christian.kandeler@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 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>
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>
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>
