None of the run configuration aspects that are added to each runconfig
depend on the actual runconfig, only two need the target, the rest
nothing at all. So use target as common denominator.
Change-Id: I31829e63ac79d5c707bb068d73fc6a4687cb4c47
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
... and adapt constructors to not take the now-unneeded
RunConfiguration pointer.
Change-Id: I53ff338f51334ff7b0c22d4bed92bfcfc8225ea7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Not really needed, a QWidget does the job, too, and de-emphasizes
then 'Run' bit. The display name is now taken always from the
aspect, but that's what was the practically the case before,
albeit with different implementations.
Change all names to *[cC]onfigWidget* (in line with ISettingsAspect).
Change-Id: Ida0409a2dd0b175dd5ce4202f9b9e94b3f2db421
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Any SettingsAspect that doesn't refer to the global settings has a
specific RunConfiguration it is about. This can be very handy to know
when constructing the actual settings. Right now there is no way to find
out about it.
Drop the clone() and create() methods. They weren't used anywhere and a
proper implementation should take care of the runConfiguration member.
Change-Id: Ie505a9b19707f8a1b6bf9cae73513cd3c30d0bca
Reviewed-by: hjk <hjk@qt.io>
Moving aspect data closer to real Value semantics fixes
the regression introduced by 890c1906e.
Task-number: QTCREATORBUG-19186
Task-number: QTCREATORBUG-19192
Change-Id: Ieaeef3995ae06a817f266c1e2514f9e5793bd4e8
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
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>
Flushing data while the application is running can distort the results
because the flushing itself takes time. However, not flushing leads to
longer load times in the end and higher memory usage. The best strategy
depends on the application being analyzed and the users should decide
if they want to flush or not.
The settings infrastructure also paves the way for preserviing the
layout of the timeline and statistics views as well as the category
filters across sessions.
Change-Id: I2cdc37c7fc7eb9b05b6870955ddffaa712d6c956
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
