On Monday, 12 March 2018 11:06:59 CET Aleksey Kontsevich wrote: > 12.03.2018, 11:25, "Volker Krause" <vkra...@kde.org>: > > On Sunday, 11 March 2018 16:23:33 CET Aleksey Kontsevich wrote: > >> Thanks, Volker, for the answer. Will think more and try it in action > >> provider<->server<->analytic app to see how it works to better > >> understand. > >> However still have some concerns: if I want to get such id from the > >> server I need to write separate logic, API, etc. I see that we can > >> create, subclass, extend data sources. However Provider is not such > >> extendable, and sometimes it is not very convenient to use it in some > >> external, non-KDE applications. Could we ask You or participate in > >> development to make it more modular, extendable, flexible and > >> maintainable, i.e. to follow Single Responsibility Principle and other > >> S.O.L.I.D principles. Provider does to many things: aggregate data > >> sources > >> network communications > >> schedules submissions > >> writes audit log (log text file could be changed to DB for example if > >> moved to separate class) writes setting (QSettings could be changed to > >> SettingsDatabase class) doubles some data sources > >> Could we move some of these to separate abstractions, like: network, > >> log, > >> settings. For example if we want to change/extend some network > >> communication logic with the server: > >> get unique ID from the server > > > > Why do you need to retrieve a unique id from the server? That seems > > unnecessarily complicated for what could be done by a QUuid locally, no? > > For server to control it gives unique ID from same pool to every machine > connected.
You could still do that as part of the custom data source, the request does after all only have to happen once, rather than on every submission. > >> Also I created my own dialog to view collected statistics from user side > >> (frontend) to replace AuditLogBrowserDialog. As I saw in the sources, I > >> can attach AuditLogUiController to my dialog and view information stored > >> in *.log files. However it is not connected to Provider and I can't see > >> current raw statistics. I found such possibility in the code, however it > >> is not documented and not very beautiful as ProviderPrivate::jsonData() > >> is hidden by PIMPL-pattern implementation for some reason: > >> QByteArray jsonData; > >> QMetaObject::invokeMethod( > >> m_feedbackProvider, "jsonData", > >> Q_RETURN_ARG(QByteArray, jsonData), > >> Q_ARG(KUserFeedback::Provider::TelemetryMode, > >> KUserFeedback::Provider::DetailedUsageStatistics)); > >> // Show JSON statistics > >> > >> ui->textBrowser->setPlainText(QString::fromUtf8(jsonData.constData())); > > > > The audit log features is for users to inspect everything that has been > > sent so far. For the current data that would be sent going forward, see > > FeedbackConfigWidget/FeedbackConfigUiController, that's probably the more > > interesting UI part. > > Actually I took above code from FeedbackConfigWidgetPrivate, line 72-74. As > I mentioned such structure not very convenient and clear: good to have > single model and single controller for the statistics: current and > archived. That depends on how your UI looks like, the reason this is separate currently are: - data source might be added/modified/removed over time - not all applications might want to use the audit log feature in the first place.
signature.asc
Description: This is a digitally signed message part.
