That makes the high level sequence of operation the same as for the
local socket case.
Change-Id: Ib8af2a7826a482e98b75fe00f3c0e672b98886c5
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The connection timer was traditionally used in cases where
the application was started without being given a port on the
commandline. These setups do not exist anymore or have been
changed to provide a suitable port on the commandline.
Change-Id: Ib4653e73943819762f0c8162cc13e4da789705a7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We need to indirectly verify that the profiler support is doing the
right thing by watching the RunControl's state transitions.
Change-Id: I8f92f21022668ed3bb28477152132ccdcffaaea6
Reviewed-by: hjk <hjk@qt.io>
Writing to the label is all it does, and that crashes if the label is
gone.
Change-Id: I23bbbe0c46603a8de91143ee6167cb404c1b0004
Reviewed-by: hjk <hjk@qt.io>
We need to start the local server before the application, as the
application has to connect to it. If we use a TCP connection, we will
retry. So it doesn't hurt to start it before the application, either.
Change-Id: I64c24f922040d0ac58fe4f05abffef9ec24e3e9a
Reviewed-by: hjk <hjk@qt.io>
There will be stopDependencies, too, which apply when stopping the
runcontrol.
Change-Id: Id72771d28cbb6b254572c9f93db93e0d054b890f
Reviewed-by: hjk <hjk@qt.io>
76:5: warning: instantiation of function 'QTest::qCompare<ProjectExplorer::RunControl *, nullptr_t>' required here, but no definition is available
qtestcase.h:180:5: note: expanded from macro 'QTRY_COMPARE_WITH_TIMEOUT'
qtestcase.h:89:17: note: expanded from macro 'QCOMPARE'
qtestcase.h:364:10: note: forward declaration of template entity is here
76:5: note: add an explicit instantiation declaration to suppress this warning if 'QTest::qCompare<ProjectExplorer::RunControl *, nullptr_t>' is explicitly instantiated in another translation unit
qtestcase.h:180:5: note: expanded from macro 'QTRY_COMPARE_WITH_TIMEOUT'
qtestcase.h:89:17: note: expanded from macro 'QCOMPARE'
Change-Id: I0d9ed4eb9109cbc93439f655781cee34331719ce
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
QTimer::singleShot postpones the execution of the test methods. If we
return from the current test method before, we might end the test run
before the code gets executed. This was hiding failures.
Change-Id: I0250cd37e5b25f2a72752a2d6f3abcac3314946a
Reviewed-by: hjk <hjk@qt.io>
The timeline models were suspended for editing but never restored. To
test the correct behavior a test case for the trace view is added.
Change-Id: Ic1803e9d84656eed97795f1f1674e3d56c83f650
Task-number: QTCREATORBUG-18354
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... and make use of it.
With gcc 7, the new option -Wimplicit-fallthrough is introduced and
added to the -Wextra set, triggering dozens of warnings in our sources.
Therefore, we annotate all obviously intended fall-throughs. The ones
that are still left are unclear and need to be checked by the respective
maintainer.
Change-Id: I44ead33cd42a4b41c28ee5fcb5a31db272710bbc
Reviewed-by: Nikita Baryshnikov <nib952051@gmail.com>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
A header file was indirectly included in debug mode.
Change-Id: I9142fc9b92fd6db1182c6602a0ac4a723aa2c9f7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
A RunControl is re-runnable if all its workers are,
a RunWorker is re-runnable if it's Stopped and unless it
says otherwise.
Also ensure SimpleTargetRunner only reportStop() once
per run and make process error message re-usable.
Change-Id: I73f5fb724d3026ceb81d5e32a3a71b4814b2bca9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It turns out that one "Connection" per RunControl doesn't map
well to the uses we have. Instead, RunWorkers need to know
individually how to connect to the place where they can work,
but they are already specific enough to be able to use a
standard class (like QUrl) as their way to specify the needed
entry point.
In theory one could see a RunControl's connection as an
aggregation of its workers connection bits, but that does
not really seem to be needed in code.
As consequence, replace UrlConnection by a plain QUrl, and also
the HostName connection by a QUrl with hostName set.
Change-Id: I40c97e37779314ac0a77041e864a18eadb78f987
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
Not needed anymore, effectively replaced by RunWorker start/stop.
Change-Id: I7483c841cdd4e05c9e1f7636a27b20ece37947c2
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Displaying short descriptive text of a TextMark at line end.
Currently implemented for ClangTextMark and BookMark.
Change-Id: Idc6b579bda0382ad94b2e236b715696396b10460
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
The change is purely mechanical. QmlProfilerViewManager
is an internal class, not even extra #includes are needed.
Change-Id: Ia28b3a90c8c7dfeb1eb2510b4030c566bc264a46
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Having the overall runworker setup closer to the general pattern
allows to re-use SimpleTargetRunner.
Change-Id: Iff151cbebaa6ae6615b933f4277b0581a43d7f7f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
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>
AcquiringData to ClearingData is a valid transition, for example when
the application crashes. We don't want to drop all models then.
Change-Id: Ibb1b5a551e0dbec121a44054d36c132d038153f4
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Apparently macOS will block the event loop until a real mouse click
happens if you open and close context menus in quick succession. When
it does that, the timer won't hit anymore and the mouse event to trigger
the next test step won't be generated.
Change-Id: Ie0c05d8a5a2020fe46381358133cd7cdbbf42299
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
When moving the mouse pointer out of an item the window should not
disappear, so that you can reposition it then.
Change-Id: Ic2fa0e41bcab5fada6c3c5fca68a5f82fcd0fc7a
Task-number: QTCREATORBUG-16698
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The context menu event can be generated multiple times within one loop
of QTRY_VERIFY. The result is that multiple showFullRange() signals can
be generated before we check again for spy.count() == 1. Thus, the check
never succeeds and the number of signals keeps growing.
We connect the showFullRange() signal to the model manager in order to
get a more realistic test setup. This way the action that generates the
showFullRange() signal is disabled in any further context menus, just as
it is supposed to be. In addition we can now check for the manager to
actually show the full range.
Change-Id: I5e13c2666ce1a15c7a5fad57affd4274d9656656
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Q*Application classes have unusually many static functions. In many
cases in our code, these functions are unnecessarily called as instance
functions, using the qApp helper.
This patch replaces many occurencies of qApp with the according
Q*Application classname.
Change-Id: I6099a419fa7bf969891269c37ed7a9e817ef5124
Reviewed-by: hjk <hjk@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>
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>
If the context menu disappears for whatever reason, just open a new one.
Making sure that the context menu stays around when we don't do anything
is not Qt Creator's job, so we don't have to test for it. Also, when
trying to remove the context menu, click a spot that's certainly inside
the screen.
Change-Id: If6e574d84bedf2ab552c8c29d756501e9d2282bd
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
As we are using this as a queue, with many calls to takeFirst(), a
QVector is prohibitively expensive here.
Change-Id: I151452ae1299ab520a3aceae7ff3da0e29fe9bf9
Reviewed-by: hjk <hjk@qt.io>
