QmlProfiler: Expose flush interval to user

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>

src/libs/qmldebug/qmlprofilertraceclient.cpp

@@ -43,6 +43,7 @@ public:
         , recording(false)
         , requestedFeatures(0)
         , recordedFeatures(0)
+        , flushInterval(0)
     {
         ::memset(rangeCount, 0, MaximumRangeType * sizeof(int));
     }
@@ -62,6 +63,7 @@ public:
     bool recording;
     quint64 requestedFeatures;
     quint64 recordedFeatures;
+    quint32 flushInterval;
 };
 
 } // namespace QmlDebug
@@ -76,7 +78,7 @@ void QmlProfilerTraceClientPrivate::sendRecordingStatus(int engineId)
     QDataStream stream(&ba, QIODevice::WriteOnly);
     stream << recording << engineId; // engineId -1 is OK. It means "all of them"
     if (recording)
-        stream << requestedFeatures << quint32(1000); // flush interval. Fixed to 1000ms for now
+        stream << requestedFeatures << flushInterval;
     q->sendMessage(ba);
 }
 
@@ -152,6 +154,11 @@ void QmlProfilerTraceClient::setRequestedFeatures(quint64 features)
     d->requestedFeatures = features;
 }
 
+void QmlProfilerTraceClient::setFlushInterval(quint32 flushInterval)
+{
+    d->flushInterval = flushInterval;
+}
+
 void QmlProfilerTraceClient::setRecordingFromServer(bool v)
 {
     if (v == d->recording)