Aspect creation must stay for now as the object pool is the only
central registry for it right now.
Change-Id: Ibe42009db6b0351aaa36e9ac8f0f6f7a0562167e
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It turns out that one "Connection" per RunControl doesn't map
well to the uses we have. Instead, RunWorkers need to know
individually how to connect to the place where they can work,
but they are already specific enough to be able to use a
standard class (like QUrl) as their way to specify the needed
entry point.
In theory one could see a RunControl's connection as an
aggregation of its workers connection bits, but that does
not really seem to be needed in code.
As consequence, replace UrlConnection by a plain QUrl, and also
the HostName connection by a QUrl with hostName set.
Change-Id: I40c97e37779314ac0a77041e864a18eadb78f987
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
This kind of conflicts with the Alt-V + [0-9V] FakeVim short cuts,
but since those are rarely used and still operational in edit mode
I think that's acceptable.
Change-Id: If232cc6574690e0219eddcaa89d844f498687b64
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: David Schulz <david.schulz@qt.io>
It's nowadays a duplicate of a subset of what DSP::remoteChannel
provides.
Change-Id: I95363bd392cb1d24fb1f1e0a2780c2c295929cea
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... and QmlProfilerRunner::Configuaration by PE::UrlConnection,
and call it 'serverUrl' on the user side.
That's the only variant we ever had and avoids "translations"
between three structures that are essential the same.
Change-Id: I33386b2b8d2a7985ff934f6f8f840de0831bf9c1
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Nobody complained for more than a year, this is good to go.
Change-Id: I83811513f9be364a160ad86ecf7ca45a77529e6d
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
There were only two used target states, and in case of mixed
debugging all parts of the machinery better agree on the
direction. So one bool in the (shared) runTool is sufficient.
Change-Id: Iffbf1651b82dde707cfc37d8da9d3da573b34b76
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The parameters belong to the run control, they should not
be triplicated in case of a combined engine.
Change-Id: I4dd84220edbd7a44b902cc52627fe01d0568db75
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This increases re-usability of activities like 'port gathering',
and makes their use less dependent on actual device implementations.
Change-Id: I017cb74874f2b38c487ba2d03906a675d5618647
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Remove some now-unusual connection to RunControl::finished
and use a finished() callback in the ToolRunner implementation
instead.
Change-Id: Ieddf05a2258d9a300ac50a739d77d9cfaee10ca6
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
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>
