Avoid using remote/local as (not user visible) names. 'internal'
means 'whatever the current target does', i.e. could be a remote setup,
'external' means 'attach to something running or waiting.
Also user setServerUrl() directly on the worker, no need go through
the 'opaque connection' mechanism here.
Change-Id: Id0e694562ce7d3129c7d0b790c91d465de24b4e4
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Orthogonal concepts, that only happen to coincide.
Also, make the server directly settable instead of relying
on the runControl's connection().
Change-Id: I2472acafcc50aede2cb6f99421901f0e67531b91
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>
Also streamline code paths in the result.
Change-Id: Id7d96343a8f778ba8f415b1a850cc78576afa475
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This also re-enables the remote linux case and enables
the recording of a single run of events.
Change-Id: I9ea55017c8e5f2f17e6f32c5453df48093e41931
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
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>
We keep it private to QmlProfilerModelManager and proxy the last few
methods that were directly called on the model. This enables us to
remove the QmlProfilerDataModel class by integrating what is left of it
into QmlProfilerModelManagerPrivate in a next step.
Change-Id: Ie9b4e03fb286e5a0040374d00b7b26f810426278
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The text marks are little labels next to the lines in the editor
that tell you how much of total run time was spent in the
respective QML/JS construct during the last profiling session.
This is similar to what the valgrind profiler does.
We add the text marks only when the documents are loaded into an
editor. This keeps the number of text marks manageable. Multiple
events on a single line are shown using a tooltip.
Task-number: QTCREATORBUG-17757
Change-Id: Ie38b8ab880a718a1ef72ef343d84070ab34bc5bc
Reviewed-by: hjk <hjk@qt.io>
There is no line 0, so if the document is already open, the editor
won't move to the beginning. Use line 1 instead, so that we jump to the
location of the corresponding text mark.
Change-Id: I0c5605d2d48b02d73dd97ddc87a527cf1b5dba8f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This is the place where we need it most. In addition, this allows us to
use the DetailsRewriter's cache also on gotoSourceLocation.
Change-Id: I14e0f11ba7c8a2a3888b2e8439a375068b36e29a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
And then, drop some methods we don't need anymore.
Change-Id: I057bdc012072abddca2df83918ee9a0460f78611
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This works around QTBUG-56746, by decoupling the dialog from the
context menu.
Change-Id: I2f13b01003a10598e6f69b14bb7eb8e9141acad8
Task-number: QTCREATORBUG-17149
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Clicking on something in the QML profiler should never trigger a switch
to a different mode.
Change-Id: I4784e836b0091d44fd046b605c49d2b10b3e8c34
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Pasi Petäjäjärvi <pasi.petajajarvi@theqtcompany.com>
This way we can use them from libraries, not only from plugins.
Change-Id: Ic35cfd5f04d638d87606bf272b2c00ded1267c1b
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
The client manager should not be bothered with details of QML events,
but rather just connect the client, the model manager, and the state
manager.
Change-Id: Iec4499f8441a06d4ef5cbcf7bfe23da6f5e7f239
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Remove the PIMPL pattern, use smart pointers, add asserts for
important preconditions, add a timeout also to the local server case,
make sure all signal/slot connections to the old connection objects are
cleared when retrying to connect, make retry intervals configurable.
Change-Id: Ica7df0eaddc48778f13905795871d522401617ed
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@qt.io>
and show it on any kind of connection failure, not only on timeout.
Change-Id: I6b9c44cd3455d5dd383a552f9b422d3d236b67c4
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... to follow the convention for setters.
Change-Id: Id471a93a1be1beed0438fed710fa09afa5ee2832
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Previously, in AppStopRequested state we would wait until we are done
processing the data. This is problematic as when aggregating traces
this doesn't happen spontaneously. If we've explicitly asked the
process to terminate it's safe to do so after receiving Complete as
we won't need any more data after this.
Change-Id: I64111ce6039ffc7f6815425c6b7e4432ac528c86
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Otherwise we can run into an inconsistent state when we try to restart
the process while we're still "waiting" for it to die.
Change-Id: I82afd272a73b3be79328c45c8d027621d1feeace
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The idea is to have a way for tools to specify what kind of
control channel they would like to use to communicate with
a device without making the choice explicit dependent on
the exact kind of tool to further decouple device and tool
implementations.
The 'hint' values are there to help the device implementation
to decide on which channel to use exactly in case there are
multiple choices. In any case, the tool is responsible to
check that the returned channel is suitable for its operation.
Currently the only choice is "QmlControlChannel" yielding
a simple wrapper around the former IDevice::qmlProfilerHost()
return value.
Other enum values may potentially be {Tcp,LocalSocket}ControlChannel
(to specify a type of transport) AdbChannel (to specify some
generic helper mechanism). It might also turn out that something
more complex than an enum will be needed, e.g. to express
a set of values with priorities or such, but I'd rather
avoid overengineering for now.
Change-Id: Id386425eb3dd2bb395065f0bdb6f67217cd40a71
Reviewed-by: Ulf Hermann <ulf.hermann@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>
Storing traces in binary form is preferable as loading and saving is
faster and the trace files are smaller.
Change-Id: Ia7340ac526d5ce9391b1e32fc48fc1fab3ffa13d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Some models check the visibility to determine what to load.
Change-Id: I94d42ddc6e531d04f240c66d4b789826d8c17cf6
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
These file were not used anywhere else and had no business to be in
qmldebug to begin with. Moving them allows us to drop a number of
namespace qualifications and forces us to rename a few local symbols
in other classes in order to avoid name clashes.
Change-Id: I658ed455eec027cbaddacf2980d2ea6827ae6205
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
We might have opened or closed projects since the last time we
populated the finder, and we will need the files from those projects
to resolve file names in the trace.
Change-Id: I5979702a105c60e1be452b0b029d01d7498bff3d
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
And use it in the menu entry for
"Window->Output Panes->Clear"
Change-Id: Iff8c011fde8a21fd10bf52b35163eb3f63659153
Reviewed-by: Alessandro Portale <alessandro.portale@theqtcompany.com>
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>
This patch removes the locator.png icon and replaces it with a
menu-friendly variation of the zoom icon.
The current ZOOM icon becomes ZOOM_TOOLBAR.
Change-Id: I8817c5c420801351db659caa4c4190a9074be720
Reviewed-by: hjk <hjk@theqtcompany.com>
- Qml > QML
- When an icon tooltip can be considered an action name, use
book style capitalization and no punctuation.
Change-Id: I7ea6f4976f988c462160a4cdbecf14a792f8ca3f
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
Also, rename it to Core::Find. It hasn't been a plugin for a while.
Change-Id: I845885ccf18bdc1440258d523b033758d5583881
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
Helps to prevent multiple starts of the tool in parallel.
Change-Id: Ibd2d0a66e7ce08ea07604f13fbee6d18a40dfc39
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>
