Aim is to replace it with its ProjectExplorer::RunControl base.
Change-Id: I30f837050e7c016887dc4b6cfef10b947f4f88ed
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
ActionDescription was a horizontal layer of convenience functionality
covering (only) ex-AnalyzerBase based RunControl start scenarios
and gets in the way of target/tool orthogonalization.
So continue the path chosen with the removal of AnalyzerRunControl:
Remove ActionDescription by inlining into user code, then orthogonalize
tool-by-tool, then generalize again.
Change-Id: Ib597df3f4ad7b06bef06644458fa13ddca53afdb
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
It is redundant, as a RunControl has a runMode() getter.
Change-Id: Ia048b271a5003356d21f86a3f778827d23466037
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Only one code path needed once we have a RunConfiguration.
Change-Id: Ib65f471a929a0c70694dd142b4f83be7eebbe151
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The change is "conceptually wrong", the AnalyzerRunControl derived
classes' functionality should be provided by ToolRunners based classes
encapsulating/"being" the current Analyzer*Runner classes.
However, the AnalyzerRunControl is only three (empty even) virtual
functions, but a big obstacle in merging attempt due to a lot of
mechanical followup changes in downstream users.
The current construction mechanism of analyzer run controls is actually
two different mechanisms (locally direct RunControlFactories, and a
"generic" createAnalyzerRunControl wrapper for remote cases). The generic
createAnalyzerRunControl makes it difficult to migrated them one-by-one,
due to the various downstream users.
So instead of merging the per-analyzer two uses directly reduce
the "indirection" distance by removing the AnalyzerRunControl
intermediate layer. After that the createAnalyzerRunControl mechanism
can be dissolved by using normal RunControlFactories also for
the remote cases. After that, porting to ToolRunner, and combining
with ther local equivalent can be done one by one.
Change-Id: I0ddace33fcce210cf3a547ac5bb23b3d85013934
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
If the application fails to start (like an empty exe file), the debugger
remains in "active" state, and it crashes on shutdown.
Change-Id: I6ae3a98d507856ea40375edb15c9ea4605e3efc6
Reviewed-by: hjk <hjk@qt.io>
- Avoids the hassle of QRC files and manually registering mime types
- Avoids performance regressions because of mime types that are
registered after mime database has been used
- Makes it technically possible to detect that a disabled plugin could
handle a mime type if it was enabled
Change-Id: I373008b1b56e9c6b4853055f20b3eeb112a6eff9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Simplifies the only used code path through the model and a custom
signal.
Change-Id: I9bbab725cdd122b7261a8f14b101786e38e61e57
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Both wrap the corresponding Qt class, but make sure all temporary files
or directories are created inside a "master temporary directory".
Change-Id: I55461be507c828c965224c02863ea5ed9bbf9498
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Use std::function instead. Clean up API while at it.
Change-Id: I6e401ab57f5375e36710c30508c596af3f4b3385
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... to allow more fine-grained decision making for kit choosers.
Change-Id: I9a4e97f7b4f4b074e1c764f6b134c15e2896dc79
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The mode widget needs the editor manager context, not only the debugger
main window.
Task-number: QTCREATORBUG-16543
Change-Id: Ibe92043a374d9fd507e62998f67c0ce897b198e7
Reviewed-by: hjk <hjk@qt.io>
On shutdown the DebuggerMainWindow might not be alive anymore. By
connecting the signal handler to the window, rather than the plugin we
avoid dereferencing null pointers in that case.
Change-Id: I6421eebc6b1b76f176b31eafeb039d91edd3f0b3
Reviewed-by: hjk <hjk@qt.io>
Selecting the same perspective again will not result in any visual
changes, but repaint the whole window. This is unnecessary overhead.
Change-Id: If41464ea023b2085482d5ab547cd9eeb91ce047f
Reviewed-by: hjk <hjk@qt.io>
This way we can use them from libraries, not only from plugins.
Change-Id: Ic35cfd5f04d638d87606bf272b2c00ded1267c1b
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
One step further to separate the debugger environment from the
inferior environment and to make it possible to configure a
working directory. Guessing one from the inferior's working
directory is not always a good idea.
Change-Id: I33d139c0f228ec0870556b82bc6aecca0a8e62d6
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Using a lambda in the connect was wrong here, as the m_currentEngine
member may change before the body gets executed. Indirect to a member
slot again, which then can use an up-to-date m_currentEngine.
Change-Id: Ice906a31d2ba0655daffda67ae378acc98aa3698
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Make use of recent TreeModel improvements in various
tool views, push more operations into the engine-
owned data models, specifically context menu creation.
Change-Id: I479c97102b9fb81611c6461c6df1cec59295179a
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Use that in the debugger. That simplifies the logic a bit.
Change-Id: Ia72607283373ee0f89a91f347db0ef2c87cf9fb3
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
BREAKS BACKWARD COMPATIBILITY OF TOOLCHAIN SETTINGS!
* Convert old ToolChainKitInformation to new version
* Store several toolchains in one kit (one per language)
Change-Id: Ia59a2ad067c57971ec34ce9b2e43758344443755
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
We settled now on global objects being fine for the purpose
in Core and ProjectExplorer, so there's no point in using
something more fancy in the debugger.
Change-Id: I72e45f398c09d22894419c274dfbea77da0fc153
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
dynamic_cast<> breaks in cross-library situations. In the past
the issue was witnessed on Mac, this time on FreeBSD in
various configurations.
The workaround deployed here is to manually create unique
type ids in form of (addresses of) global variables.
Task-id: QTCREATORBUG-16462
Change-Id: Ie28fbb3d31d06c1a722a3d9ea808831191298e71
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Ralf Nolden <nolden@kde.org>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The main idea is to start using ProjectExplorer::Connection later.
Change-Id: Ie91eacdfb0e93ae142fec7ce32bcf554a5282122
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
With QT_RESTRICTED_CAST_FROM_ASCII making GdbMi etc operate on
QString is feasible again. Take this as opportunity to move
debugger encoding handling closer to a 'conversion on input and
output if needed, storage in QString only' scheme.
Change-Id: I2f10c9fa8a6c62c44f4e6682efe3769e9fba30f7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
