Bring it more in line with the standard pattern.
Plus some cosmetics.
Change-Id: I2297c4e72892db386c50ece7dc64bdc89f0d9010
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... by two more specialized canRun() / createMainWorker() functions
resulting in somewhat leaner code on the user side and paving the
way for introducing a RunWorkerFactory class intended to follow the
now-canonical way of having factories as members in the plugin pimpl.
Change-Id: Id6fc2043a340203f14ab0b896a8dfa1e298f58a6
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Into a trivial bit and two setters. Plan is to use it only with information
that is truly there (e.g. kit/device only) at the user side without having
to invent a RunConfiguration "handle".
Also remove some dead code in the test runner.
Change-Id: I987881e41722178b14b91f973b84cbdb67a9f85e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Mainly to get rid of the QProcess::finished deprecation warning.
Also adjust coding style in the surrounding connects when needed.
Change-Id: I12f9b248c7974b892c4a069356e578e80f8c59e9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... into items that can be used generically in project configurations
(ProjectConfigurationAspect) and items that have a choice between
global and project settings (GlobalOrProjectAspect)
Change-Id: I94831237bdbb18c339eb76eba131bf7f928933d6
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Also, use QString uniformly for the (now rarely used) perspective ids.
Change-Id: I682062e7d179d0fcfd309e7714713bd1218bd8bb
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This is a step towards properly supporting multiple debugger
sessions side-by-side.
The combined C++-and-QML engine has been removed, instead a
combined setup creates now two individual engines, under a single
DebuggerRunTool but mostly independent with no combined state
machine. This requires a few more clicks in some cases, but
makes it easier to direct e.g. interrupt requests to the
interesting engine.
Care has been taken to not change the UX of the single debugger
session use case if possible. The fat debug button operates
as-before in that case, i.e. switches to Interrupt if the
single active runconfiguration runs in the debugger etc.
Most views are made per-engine, running an engine creates
a new Perspective, which is destroyed when the run control dies.
The snapshot view remains global and becomes primary source
of information on a "current engine" that receives all menu
and otherwise global input.
There is a new global "Breakpoint Preset" view containing
all "static" breakpoint data. When an engine starts up it
"claims" breakpoint it believes it can handle, but operates
on a copy of the static data. The markers of the static
version are suppressed as long as an engine controls a
breakpoint (that inclusive all resolved locations), but are
re-instatet once the engine quits.
The old Breakpoint class that already contained this split
per-instance was split into a new Breakpoint and a
GlobalBreakpoint class, with a per-engine model for Breakpoints,
and a singleton model containing GlobalBreakpoints.
There is a new CppDebuggerEngine intermediate level serving as
base for C++ (or, rather, "compiled") binary debugging, i.e.
{Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine
base that are not applicable to non-binary debuggers.
Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Pass id in constructor, so it can be const.
Change-Id: Id33fe19c4416109af8aa05a3ed0a09918eeb5cdf
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This simplifies the toolbar setup and removes the need for the
stack of toolbar widgets.
The actions themselves have been owned by the plugin already,
so nothing changed in this respect.
Change-Id: I44754e16c8fc2acc53633dd9d560b1e732eece27
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Lifetime of the pointed-to object may end before that of
the plugin, so unique_ptr is the wrong choice.
This amends 01f2b982a2.
Change-Id: I76b9ac78348d2ae1e7eff0693b091dbe8475ab93
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It complains about alledgedly wrong spelling of "Visualisation"
in unrelated patches.
Change-Id: I047f2be4b534a7d01d8c0bc39ff22b615d2c0467
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Similar to the previous patch, but affecting more plugins: with dynamic
perspectives lifetime is better managed close to the code that knows how
to (re-)construct the items.
Change-Id: I0e7bfcf769d198ec2afa88b972be900baa1b6a46
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Callgrind runs can spread TextMarks across files. Only way to
get rid of them would be to start a new analyze and stop it
before it can add new TextMarks.
Be user-friendly and allow clearing the data including the
TextMarks explicitly.
Change-Id: If8d5c5f789414709a110249377ce907466c0fdf1
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Not needed anymore, effectively replaced by RunWorker start/stop.
Change-Id: I7483c841cdd4e05c9e1f7636a27b20ece37947c2
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... in case of "External Application" starts.
Change-Id: I6a5c215831f16c51e3cf98c35dbb792f53128d42
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It's only used internally as one-time communication between
worker and the *Tool singleton that handles toolbar button
states.
We basically start immediately after creation of the worker, so
any pre-start tool bar specific operations can be done at
RunWorker creation time.
Medium term, the runworker should proably steer "their" buttons
more directly.
Change-Id: Id6df703746ece5eebc23507739cd2a92ec55d11d
Reviewed-by: Christian Kandeler <christian.kandeler@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>
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>
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>
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>
This way we can use them from libraries, not only from plugins.
Change-Id: Ic35cfd5f04d638d87606bf272b2c00ded1267c1b
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
If the Error + popup combo is generic it should live in TaskHub.
If it is not, end user code should decide when to popup.
Not an intermediate level.
Change-Id: I195ba8c17c5cc192ff9762ed6f45629143bcbb35
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
They are needed in the timeline view.
The change in qtcreator-project.qdocconf makes sure
that qdoc still finds the referenced icons.
Change-Id: I812fba8e57d06d93efc00c295467c83c08cd1784
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@theqtcompany.com>
It's the only remaining item and loosens the dependencies of
ex-AnalyzerBase based plugins on the the Debugger.
Change-Id: I943ac44401c440dd6d3d5c1f54f8f996accd2b4a
Reviewed-by: Alessandro Portale <alessandro.portale@theqtcompany.com>
The default 0 value will be interpreted as 'use the editor stack'.
Also, drop the idea of value semantics for Perspective objects
to get a simpler approach to the destruction of owned widgets
(tools docks + central widget)
Change-Id: Ic6470411ee5d387c43447f95b5a12c81c6658ff8
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The tools are separated everywhere, lumping them into the same
RunControlFactory removes modularity artificially.
Change-Id: I8d9e917bb114a1898a0c293f18d3bf78a52075aa
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
