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>
The previous code would fail on Qt versions n.0 to n.5 with n > 5.
Change-Id: I7e9d512bab269137862370db86e0da19e250059e
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
The check is covered by canRun().
Change-Id: Id2360a5d2cb2fd915e164a6b5a533f008fe670f1
Reviewed-by: Christian Stenger <christian.stenger@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>
Instead, use the one in its (Standard)Runnable.
The change is mechanical except to the fallback to the project directory
which was introduced in 8150209f to keep some compatibility with the previous
setup of the Android runner which created and copied the fallback value around
and ignored it in the end. Not producing the fallback value is less effort.
Change-Id: Ie04da570f0f9fbc1d048f2eacaed522f7253afa3
Reviewed-by: hjk <hjk@theqtcompany.com>
... with a lot potential to code consolidation.
Change-Id: I4d3a7fcc1cc6ae8763799f18cf9701695f387791
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>
* 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>
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>
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>
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>
This provides a way for third-party plugins to implement run
modes without the need to add a value to the central enum or
using manual workarounds like RunMode(*(int*)&someUniqueObject).
Instead of centrally defined enum values this uses Core::Id that could
be defined anywhere.
Change-Id: Ic350e3d8dbb8042c61b2d4ffec993ca151f53099
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
This is what it is on the top level. The change makes it obvious
that in the valgrind(-derived) plugins the value is later wrongly
used to make a decision on whether to run the valgrind process
locally or remotely. But that's isolated in valgrind now and
can be fixed there.
Change-Id: I6fa5e669dec1f9e2cdebe42a1591d15144082a21
Reviewed-by: Anton Kreuzkamp <anton.kreuzkamp@kdab.com>
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
In order for plugins to create a RunControl for locally running
applications that do not use LocalApplicationRunConfiguration it is
required to export an API that takes care of the internal setup. Also this
removes the hard dependency on LocalApplicationRunConfiguration.
We don't want to expose Internal classes in public API, so we have to
make QmlProfiler::Internal::QmlProfilerRunControl and
QmlProfiler::Internal::QmlProfilerStateManager public.
Also, AbstractQmlProfilerRunner doesn't do anything useful and can be
removed.
Change-Id: I0403e5b17e14ac894addd818ad7b249c51a8ed8d
Reviewed-by: hjk <hjk@theqtcompany.com>
Reviewed-by: Benjamin Zeller <benjamin.zeller@canonical.com>
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
QmlProjectRunConfiguration is now derived from
LocalApplicationRunConfiguration.
Change-Id: Ieddac63ff9832771ed141c3f0aff1bcc0313f6bf
Reviewed-by: hjk <hjk121@nokiamail.com>
The Analyzer implementation is now simple and still generic enough
to serve as general base.
Change-Id: I050a21919bf128929b77a64da1f46d157691d849
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
That's taken care of the run control factories directly now
Change-Id: I1cd7470e78a93459bee878f5e32594e7cf339a91
Reviewed-by: Aurindam Jana <aurindam.jana@digia.com>
That's a needless indirection. The run control factories know pretty
well what kind of start parameters they need.
Change-Id: Ia2d92beb6512cd99254fe22e215950cc67d5d0ed
Reviewed-by: Aurindam Jana <aurindam.jana@digia.com>
Reviewed-by: Christiaan Janssen <christiaan.janssen@digia.com>
QML Profiler does not make use of the run configuration aspect.
Return the run configuration aspect for only Valgrind.
Regression introduced in Ic8279755f0188ab53253a62322fcccf1c17b6aaf
Change-Id: I568e309e72f7e7f0107bd720acc9dbbda78acfc1
Reviewed-by: hjk <hjk121@nokiamail.com>
The copyright was changed in
Ic8279755f0188ab53253a62322fcccf1c17b6aaf
Change-Id: If4251d13b6e653d49913d1c50044177491326edc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
QML Profiler does not make use of the run configuration aspect.
Return the run configuration aspect for only Valgrind.
Regression introduced in Ic8279755f0188ab53253a62322fcccf1c17b6aaf
Change-Id: I568e309e72f7e7f0107bd720acc9dbbda78acfc1
Reviewed-by: hjk <hjk121@nokiamail.com>
Separating out the run control factories is the initial
step towards separation of run control from QML profiler
engine. The goal is to to make the engine agnostic of
the run control.
Change-Id: Ic8279755f0188ab53253a62322fcccf1c17b6aaf
Reviewed-by: Christian Kandeler <christian.kandeler@digia.com>
Reviewed-by: Christiaan Janssen <christiaan.janssen@digia.com>
Having one factory per tool (or plugin) created some bugs:
* analyzer project settings being created twice
* per-project analyzer settings widget duplicated
Also, most of the code from the run control factory were copied.
Now, the Analyzer only creates one run control factory shared among all tools, and the IAnalyzerTool
has two new virtual method: canRun and createStartParameters. It simplify the code a bit, and
creating a new analyzer tool is easier (only two classes to subclass: IAnalyzerTool and IAnalyzerEngine).
Change-Id: I4e180846a26b74b2b77cb99bc97534d680a80a4d
Reviewed-by: hjk <qthjk@ovi.com>
