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>
Removes one reason to derive from base RunControls (specifically
ValgrindRunControl).
Change-Id: I81e32a49ef30e79ee7e7b53a54021eaaba43453a
Reviewed-by: Tobias Hunger <tobias.hunger@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 introduces a mini-state-"machine" to handle RunControl states
Intialized->[Starting->Running->Stopping->Stopped->]*->Finished.
Needing time between trying to start and getting feedback is nowadays
the normal setup for all remote targets as well as for most local tools.
Making that the default for all runs simplifies the code and provides an
opportunity to (a) fix some currently wrong reports of "stopped
immediately" and (b) to remove target-specific (WinRT) or tool-specific
(Valgrind, GammaRay) state members doing essentially the same.
Change-Id: I7f52fee41144188ee8389e922fdc265f8c0a6459
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Provide protected methods in RunControl to handle the notification
of when the RunControl starts and stops. Use these helpers to
move the isRunning() method into the RunConfiguration itself instead
of reimplementing it everywhere.
Change-Id: Ia8de42f7a6a14a049870d4e7fcb9af6756c2caa4
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
In the general case we don't want the QmlProfilerRunControl to parse
the QML debug port from the application output. As for most platforms
the ports are mapped via some remote connection mechanism the parsed
port is almost certainly wrong.
In the case of local connections, however, the port is actually
correct, so we keep the output parser in the LocalQmlProfilerRunner.
Change-Id: Ifdaae85196d8b034e67bc2ba0b8c05be980b62e5
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Giving individual RunControls the freedom back to decide what they want,
even if they currrently decide to use the same one.
Change-Id: Ia2acf4b9d32d23c486339b2488611038672aba25
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The tools' ability to hook into processing of the output is
retained by making the function virtual.
Also remove the unusual overload of the RunControl::appendMessage
slot and the signal of the same name by renaming the signal.
Change-Id: If3c3cc2dd9c933169dc30b16e3165c9b3cf1440e
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This solves the ambiguity between 0 and -1 being the "invalid" port.
Change-Id: I3bac11dd4117bb1820fbd58186699925b73df1c5
Reviewed-by: hjk <hjk@theqtcompany.com>
Disabled runControls would still receive and send signals, confusing
the profiler state.
Also, connect lambdas with receiver argument where possible.
Change-Id: I0cd43456d3462efe402e9d68792b67314e9b6e0b
Task-number: QTCREATORBUG-16073
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
If a run finished not by using the 'Stop Profiling' button the
Application Output pane still handled the respective tab as running.
Change-Id: I283bea73fe9df86a89e6130ad6737a86e1dc0341
Reviewed-by: hjk <hjk@theqtcompany.com>
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
On the user-visible side, only the 'Analyze' mode button disappears,
and instead a combobox to switch between different tools in appears
in the Debug mode toolbar.
Internally, that's quite some re-organzition: The centralized
'Analyze mode is busy' flag is gone, allowing us to run e.g.
ClangStaticAnalyzer and MemCheck in parallel.
Analyzer tools and debugger now share the same mechanism to
generate/load/save dock widgets.
Analyzer tools now create and handle their own start/stop button
when appropriate. In general, Analyzer tools can create/handle more
than one run control at a time.
Further consolidation is possible, e.g. RunControl state handling
could be merged into the base ProjectExplorer::RunControl to
avoid the still existing duplication in ~15 instances.
Change-Id: I91e5940ebc4211f98056d507cf2f7b5f8efe7f07
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
This is the first mechanical step to execute on the 'shared pool of
debugger/analyzer views' idea.
Future steps would be providing infrastructure for the view pool,
making all analyzer/debugger views use the pool and then re-extract
a sensible base for a 'analyzer-and/or-debugger' tool plugin interface.
Change-Id: I1bb392e6dd3084fc56937956bee1d6fd9530335d
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
These re-implementations are conceptually "too specific". Rather let
the indiviual tools handle there expectations themselves.
Change-Id: I0bbea407b2241816a40d19eb1dbb0a7589cbda7b
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
The functionality can be provided by producing a suitable Runnable
in the derived classes directly.
Change-Id: I7b8e8fe33fffd2b00176b6cf6633eca4e152e466
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Remove unneeded function arguments, Qt 5 connects etc.
Change-Id: I95faf80e7b5ccc574e2457b841f7913bc2aa05d3
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
... into AnalyzerRunnable and AnalyzerConnection and use the
RunControl's storage instead of an own copy in AnalyzerRunControl.
This is an intermediate step on the way to remove
AnalyzerStartParameters.
Change-Id: Iee7c38781b2fd6ef030dcdada1993684cbb34c74
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
* SysRoot can always be determined from kit.
* Pass around RunMode as extra parameter
not as part of AnalyzerStartParameters.
That's closer to the pattern used elsewhere.
* Environment was always initialized from the runconfig's
EnvironmentAspect. The tools can do that directly.
* Provide setter for display name for cases where
it is not equal to RunConfiguration::displayName
Change-Id: I811a0d7cdeb55cc37a16a593b3942abb567a2150
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
If we've parsed an error message from the application's stderr we can
stop trying to connect.
Change-Id: I8d58e5db19de3253681c52be1637cfddfd46a519
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
This removes the need to receive messages from the application via
stderr. The "Connecting to socket" is still parsed, but only for
diagnostic purposes. If it doesn't arrive, the profiling will still
work.
Change-Id: I022691293da2a1e671ba1263bc76e4044bf1a5b7
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
You could trigger invalid states by pressing the recording button
while the profiler was waiting for data to be loaded from the
application or by pressing the "stop" button twice. Now the buttons
are disabled when they don't make any sense. In particular you cannot
clear, change features, filter the display while recording and you
cannot toggle the recording while loading. Pressing the "stop" button
twice will cancel the loading now, similar to what happens if you
first disable recording and then stop while the data is loaded.
Change-Id: Ie5133f4bed76593dedc9763b778a2c5c17187543
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Only half of the states are useful for anything.
Change-Id: I4591ccda6eec902e929e07947bad6c3f7b967ef9
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
It's always a pain to search for the only RunControl that's called
"engine" half of the time.
Change-Id: I4cece9f8958ff989925d9efaaf6fb41731842647
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>