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>
This is the logical place to do it. Adding the event first to the QML
model and then passing it back to the manager in order to have it
dispatched to the other models is somewhat backwards.
Change-Id: I64b1cb38f97331b62d83fa5ae49b9b2690810d40
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The QmlDebugConnection might immediately signal a connection failure
on connectToHost() or startLocalServer(). If the timer is not running
then, we trigger the QTC_ASSERT in qmlDebugConnectionFailed(), which is
meant to make sure that we don't silently give up. In this case, we
haven't even given up, yet, as the timer is in fact started afterwards.
Change-Id: Ia2c107d9b511092eaf32380203a3b4628139d320
Reviewed-by: hjk <hjk@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>
A socket error is not the only possible reason for a connection failure
and exposing socket error codes to the upper layers is unnecessary.
Change-Id: I27e9f21160ecea5b0d811b83b7ab0ab9071cacff
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@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>
I doubt that anyone has ever used it.
Change-Id: Icf8c6513f5cdd10a9aa790e7373df9eba7c12ef2
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Running them through the model manager via signals doesn't make much
sense anymore.
Change-Id: I6103d281dd640493f28acd7e787ea49712ebd8df
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We want to get rid of the big master list of QmlEvent in
QmlProfilerDataModel, as that gets very large for longer traces. In
order to reduce the dependencies on that list we load the events on the
fly into the child models while they are being received, rather than
having the child models query QmlProfilerDataModel for the event list
later.
As the trace client so far only emitted rangedEvent() for complete
ranges we run into problems with models that need their events sorted.
The rangedEvent() signals were sorted by end time, rather than start
time which makes it inconvenient to analyze them in a stack based way,
for aggregation. This is solved by passing on all the details from the
trace client to the models, with the QmlProfilerDataModel aggregating
the type information before having the events dispatched to the child
models.
Change-Id: I5831a20551f21cf91e27d298a709f604ebd96c3e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@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>
This solves the ambiguity between 0 and -1 being the "invalid" port.
Change-Id: I3bac11dd4117bb1820fbd58186699925b73df1c5
Reviewed-by: hjk <hjk@theqtcompany.com>
Otherwise we might end up waiting forever for a previous session's
connection.
Change-Id: I695d7a1ce21bc9720cc84436a7c4e6ba4616b0ab
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
On windows it can take a long time to establish the connection. On OSX
we want to throw away the first connection after trying for 200ms. We
don't want to introduce #ifdefs here, so after throwing away two
connections stick to the third one.
Change-Id: I407120244747ac39429786e371c93a7d1e29933d
Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
Whenever we create the connection we as well try connectToHost()
immediately instead of deferring it until the next timeout. The
else branch in tryToConnect() would never be executed because if
the connection is there and not connecting or connected, then
the socketState must be != ConnectedState.
Change-Id: I6736b35348671961fbb3a48edb5e9c6c1d7ce915
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Sometimes it takes very long to establish a TCP connection to the debug
server. If the connection hasn't been established after 200ms we
probably don't want to wait for it any longer. If, however, the TCP
connection is there and the "hello" hasn't arrived yet, we keep the
connection in order not to trigger an unexpected state in the
application.
Change-Id: I1a64493fefc759f526cdebff434a2557077f9246
Task-number: QTCREATORBUG-15383
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
The device can exist without being open, which makes the disconnect()
when the message box finishes ineffective. Also, disconnect() merely
trashes the signals and slots, but doesn't remove the device.
Task-number: QTCREATORBUG-15383
Change-Id: I8eb8ca3db496c9841156c0949c3e3bfd92329056
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Otherwise some engine can stop recording by sending a "Complete" event
and that will be the state we send to any new engines, although the
recording button was checked when the recording started.
Also, don't redirect state changes and the associated recording state
sending through a signal and slot. This allows us to remove the
"enabled" property of QmlProfilerTraceClient and adapt the signature
of sendRecordingStatus() to facilitate the redirection of newEngine()
through the client manager.
Task-number: QTCREATORBUG-13317
Change-Id: Ie9dc6785eb761514bc96aaf5724f7b23d3c2932e
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
In particular, they can also occur if we're not AcquiringData.
Change-Id: Ia310206ee15973fc5b2fa1c607d7c9a48b6f435f
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>
There is no point in sending two signals for every state change and
error. Also, the signals only reflect events in the socket, not in the
logical connection.
Change-Id: I617a925c69164aa1a02a7781b9da7dca55daa304
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
This is to adopt the naming to the code in src/qmldebug in
qtdeclarative. Once we can require a version of Qt that has qmldebug
for building QtCreator we can then remove our own version of this code.
Change-Id: I573f0703871b5812789c5c7a6287567d5c2875e6
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Now that we don't recreate the debug connection anymore when (re)trying
to connect, we have to do it explicitly when changing the connection
parameters or when a connection attempt fails and we need to cancel the
"Connecting" state.
Change-Id: Ib2b6b4fb1e39e64fe3c9f2bf90b6e43043d05a9e
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
If we're already trying to connect when the "Waiting for ..." message
arrives we don't want to start from scratch, but rather reuse the
existing connection.
Otherwise the handshake may be interrupted in an arbitrary state,
either leaving the remote QML engine waiting for the local QML profiler
to send the recording status, or prompting the local profiler client to
stop recording as the connection "broke".
The local QML profiler will only send the recording status if new QML
engines show up, which doesn't happen on the second successful
connection. That may be a different bug.
Change-Id: Ia17fcf9d0a28edf700274bcd88c2b7030220c290
Reviewed-by: Robert Loehning <robert.loehning@theqtcompany.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Only half of the states are useful for anything.
Change-Id: I4591ccda6eec902e929e07947bad6c3f7b967ef9
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
It doesn't do anything useful. Also the qmlDataReady member is
write-only and can be removed.
Change-Id: I667b05611cfc5960eb2fd73254a7b3c621ae98a3
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
The complete() methods do something more specific. We should call them
by what they do. Also, we don't need to signal the finishing of data
acquisition via a signal and most of the postprocessing can happen in
the worker thread.
Change-Id: Iae986aefb8e7e7d4327c481d7a85325bbff7fa48
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Whatever that is, it definitely didn't work.
Change-Id: Ib15b9dcad6e22d52285a253b234989e55d817268
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>
This way we can have a central filter menu to hide and show features
in any connected views.
Change-Id: I8142da0062a23f8166555016de6c7cb38060f725
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
