Make the aspects private, but provide accessors to value and
defaultValue as needed. This allows setters to be kept protected
when wanted.
Change-Id: I26f93f62d4ac2e7346f95543c38d8ac9156348c2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Motivation:
a) It was ridiculous that when users wanted to manually
add a new toolchain, they had to do the entire setup twice.
b) It was equally weird that users had to take care to choose
matching toolchains when setting up a kit, or indeed that it was
even possible to mix random toolchains in the first place.
User-visible changes:
- The "C" and "C++" categories in the toolchain settings page have
been merged into a single "C/C++" category.
- When adding a new toolchain, the "C" and "C++" sub-menus are gone.
Instead, the toolchain config widget offers two path choosers if
the respective toolchain type supports C and C++ compilers.
- By default, the C++ compiler file path is derived from the C
compiler file path automatically, so the user usually has
to enter only the former.
- In the kit settings page, the "C" and "C++" toolchain combo boxes
have been replaced by a single "C/C++" combo box, relieving the user
of the responsibility to choose two matching toolchains.
Implementation:
The notion that a Toolchain object corresponds to a single compiler is so
deeply engrained in the code that it cannot realistically be changed in
the short term. We therefore introduce the concept of a "toolchain
bundle" as an additional layer that groups matching C and C++ toolchains
together. This way, most code dealing with toolchains stays unchanged,
and only the presentation layer (i.e. the toolchain and kit settings
pages) needed to be rewritten. Once set up in a bundle, toolchains stay
implicitly linked together so the matching only needs to be done once.
In follow-up patches, we will make use of toolchain bundles in all the
places where kits are auto-created, eliminating the risk of mixing
incompatible toolchains in a kit.
Change-Id: Ie6c5add9963e7c1096268dd77acd624671b2674f
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
This is effectively the same approach as taken with ProjectConfiguration.
Having the settings separate leads to quite some boilerplate and in the
end to parallel IDevice and DeviceSettings hierarchies.
The unusual registration of the docker aspects are due to the multiple
inheritance, we need to "dynamic" downcast.
Change-Id: I50864e2009f4e525d635decf1c9beaad5e6a5f1f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
From Store toMap() to toMap(Store).
More symmetric code on the user side and better in line with
ProjectConfiguration/AspectContainer at the price of a few
more lines in the base.
Change-Id: I6069c96c250c1846e870879bcb52c58fdd806478
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It has some platform specific warts, filepath.h is somewhat
cheaper and less ugly overall.
Partially clean up surroundings
Change-Id: Ida1fd470ec020f69c446109427f92a08e879789f
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
We do not need different code paths for Xcode < 9 nowadays.
Just tell simctl too boot the requested device and make sure the
Simulator app is running.
This also fixes an issue if for some reason a different device is already
booted without the Simulator app running, e.g.
1. make sure Simulator is not running
2. boot a device from the command line with
`xcrun simctl boot <deviceID>` (get the device ID from the Devices &
Simulators window in Xcode)
3. start Qt Creator and run an application on a *different* simulator
device
Without this patch Simulator app opens with the device from (2) and
deployment of the application fails for the different device.
With this patch the device for (3) is booted and the application
deployed and run.
Change-Id: Ifce8c470f2d4d646295ca4e47fbd92308f87adf8
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
If simctl fails, always include its stderr output in the error, if any.
Change-Id: I7a5643ac81befc9d0595e9c3bd4fa009057ff85b
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
It was set, but nobody was actually using it.
Change-Id: I99c6fcd4605591d65e5f3fb3f489a3de0c61fb24
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
In case of error, post the output of the simctl command in compile
output and issues pane.
Fixes: QTCREATORBUG-25833
Change-Id: I62a0f7b10b5188a7c8b4e1db543b66d0661d4e6a
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
The TaskAdapter may be destructed at any point in time,
even when the task is still running (i.e. when the task tree
was canceled). Make sure the internal IosToolHandler gets
deleted in this case.
Amends 150441bf88
Change-Id: I1ae4d324390c38d4faf9ec32f83c66295ed18532
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
It's conceptionally const, and would be useful to use as such, but
the current implementations often modifie mutable state.
To ease the transition pain, rename the previous non-const version to
addToLayoutImpl() and call it after const_cast'ing.
Change-Id: Ic8ca38e40f5df69c3d11121f96ea37648cf4feb7
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Where they were missing. The text is shown as a paragraph in the
extension manager.
Change-Id: I6e15c89fe4023b222e9c476f4312e13fcb0905c0
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
When starting the debugger, we need to pass it the location of the
downloaded device symbols, or otherwise debugger startup is very slow.
Xcode changes the location where it saves this information once in a
while, and it must have again. The location with Xcode 15.2 at least is
in the style "iPhone8,1 15.7.3 (19H307)", i.e. it starts with the
"product type" now.
Retrieve the product type of the device and add another candidate
directory for device symbols.
Fixes: QTCREATORBUG-31044
Change-Id: I1a65305fc84c1af8cd48c4ebb249167e1dbe6ae1
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Edited the short descriptions to answer the question
"What can I do with this extension" to help users decide
whether they need it.
In long descriptions, tell users what else they need to
be able to use the plugin.
Change-Id: Iefce7505b61fc77cf38cc915f1f7dbd25c9cb570
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Avoid the redirect that is inevitable nowerdays.
Also, change necessitas.kde.org to www.qt.io, since the orgininal page
is offline.
Change-Id: Ib1823f0df97d2df87822fd2bb7552e2f2c7e971e
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
This puts the implementation introduced in acf1ecb47f into use, after
significant simplifications in the class hierarchy. CRTP is not used
anymore, and the new tag based dispatch is also used for Layout::addItem,
effectively reducing the number of different code paths.
The Lua based settings access is disabled for now.
Change-Id: Idb6d1a25675378757c5267bdb630bcd4c1f52d34
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Use the global synchronizer from Utils::futureSynchronizer() directly
Change-Id: Ic8843bc1ff7951c041529a258f36117f08ec4b35
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Qt Creator would crash when starting an app in the Simulator while
another app is running, and the old app is not killed by the deployment
before run. This could happen in two cases:
1. Running an app in one simulator device and starting that or another
app on a different simulator device
2. Running an app in the simulator and starting that or another app on
the same device without deployment
In the first case, it actually doesn't make sense to stop the running
app, the Simulator can run multiple devices simultaneously (this might
have been different in the past).
In the second case, the new IosRunner initiated a stop of the old
RunConfig, and while that was in Stopping state, the app output window
tried to re-use the old tab and deleted the old RunConfig. This lead to
an assert in the RunConfigPrivate destructor, which only expects to be
deleted when in Initialized or Stopped state, and eventually to the
crash. The app output window should not reuse tabs that are not
"Stopped".
Fixes: QTCREATORBUG-30666
Change-Id: If46904dd487301e465e89ce7946be375ab4bdee8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Simulators can be managed via Xcode, which must be installed anyway. Re-
implementing this functionality is not useful, error-prone, and a
maintenance burden. Point users to the corresponding Xcode documentation
instead.
Add a button for updating the list of simulators in the run configuration
settings (which didn't update when simulators were changed in Xcode).
Change-Id: I5a861f21851bb866d45a703f46bb20ed5df960e8
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
This is done by the FutureSynchronizer d'tor, so no need to call
it explicitly. Move the FutureSynchronizer as the last field of
CreateSimulatorDialog so that its d'tor is executed first.
Change-Id: I861e4c6498b63909fe52965ca16343ef82d20b42
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
That were configured for a project.
The crash is triggered by a messy combination of the Android automatic
kit creation, project window update, and automatic creation of Qt
versions and kits by the automatic project importers, including a mess
of the listener pattern without any atomicity.
- the user removes the Qt versions
- the Android plugin updates the automatic kits and individually reports
the removed kits (*)
- that triggers an update of the project window and an update of the
target setup page (even if that is not shown, but that's yet another
issue)
- that triggers the project importers, which add Qt versions, which in
turn triggers another update of automatic kits in the Android plugin -
while that is still in the reporting loop at (*)
- that leads to the crash, because the state at this point of time is a
mess
This minimal fix of the specific crash makes the kit update reporting in
the Android plugin at (*) "more atomic", and the same for similar code
in the iOS plugin.
Fixes: QTCREATORBUG-30347
Change-Id: I2bea6fb735abcaa34469fc43f44aa37313f70429
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Rename process.h back to qtcprocess.h
MSVC's "threads" standard header includes <process.h>, and that ends up
including our process.h from Utils.
There already was a hacky workaround in place for a similar issue with
MINGW, but that doesn't work with MSVC because that doesn't have
Simply use a name that doesn't conflict.
Change-Id: I1159cd2096b4f2dbc4a1728d0131dd6edd30ebd3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
It's the "persisted" form of the content of the original aspect's data,
calling it 'aspect' already confused me a few times.
Change-Id: I88a6f76f0ca39d3d36dde9b84287032ceecf7033
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
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>
And add a test to document what we expect from devicectl.
Change-Id: Ic69af99a472976a6c06801a646af59f8139d5624
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
And add a test to document what we expect from devicectl.
Change-Id: I2f5312ebadef60239b77308acb7114f1d55143b4
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
And add a test to document what we expect from devicectl.
Change-Id: I395171bb5316c21b461a01dce5c9ec87d81fb0c4
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
It can happen that this is triggered twice for the same device, or for
other devices when the dialog is still open. This looks funny and is not
necessary, so avoid it.
Task-number: QTBUG-121557
Change-Id: I0329104b3825b68b565ca1f8e00d785952c9d767
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
