Re: kdereview - xdg-desktop-portal-kde
On pondělí 1. května 2017 22:59:44 CEST Albert Astals Cid wrote: > El divendres, 21 d’abril de 2017, a les 8:10:36 CEST, Jan Grulich va escriure: > > Hi, > > > > I would like to request review of xdg-desktop-portal-kde [1]. We would > > like > > to make it part of Plasma releases, see [2]. > > > > What is xdg-desktop-portal-kde: > > It's a KDE implementation of Flatpak portals backend [3], currently with > > support of AppChooser, FileChooser, Notification and Print portals. > > > > One mentioned issue on plasma-devel mailing list was usage of Qt's private > > print API. This will most likely go away if I find out it's useless, > > otherwise I'll have to keep it as it's used to set CUPS properties which > > are not available to the outside world. > > Since you have copied some code from Okular maybe you can add some other (C) > there other than RedHat's? Added. > What about the unusued QVariantMap in the print.cpp file? What are > you supposed to return there? Seems not to be used at this moment or the portal frontend doesn't expect something to be returned with "results". I guess it's just reserved for future usage, given how complex the print API is. > I've no idea how to use this so can't really test it :/ You can test it with this [1]. You just go to flapak-build folder and run build.sh which will generate you a flatpak repo, you add it and install using flatpak, but you also need to have xdg-desktop-portal installed. [1] - https://github.com/grulja/flatpak-portal-test-kde Regards, Jan
Re: Application usage statistics and targeted user surveys
El diumenge, 23 d’abril de 2017, a les 12:52:57 CEST, Volker Krause va escriure: > Hi, > > we have talked about the above topics a couple of times in the past, from > what I remember usually agreeing it would be nice to have some more > statistical information about our users, so we know what our applications > are used for, and to measure impact of changes. Similarly, it would be nice > to be able to actually ask our users questions without statistical bias by > using out-of-band channels like blogs or social media. This can be > obviously addressed by adding this into application code, but that raises > some valid privacy concerns. > > Wanting this for GammaRay I attempted to implement a generic framework for > this, with the goal to make this fully transparent, and give the user full > control over what data is shared, and how often they want to participate in > surveys, ie. make this solid enough on the privacy side that even I would > enable it myself. You'll find the code in Git (kde:kuserfeedback). Why the weird values in StatisticsCollectionMode ? Should submissionInterval and encouragementInterval also be a property in Provider? Also would be nice to specify the default values for submissionInterval, encouragementInterval, surveyInterval Do I gather correctly thta as an app developer the only things I'm actually interested in are Provider and FeedbackConfigWidget/Dialog? Would be nice to have some docu saying so > > Feature-wise it so far contains: > - a set of built-in data sources (app version, Qt version, platform, > application usage time, screen setup, etc) that applications can choose to > enable > - generic data sources for tracking the time ratio a Q_PROPERTY has a > specific value, allowing to track e.g. which application view is used how > much - the ability to add custom/application-specific data sources > - reference widgets for customizing what data you want to share, and showing > exactly what that means, in human readable translated text and if you > insists also all the way down to the raw JSON sent to the server. > - survey targeting using simple C++/JS-like expressions that can access all > the data sources (ie. you can target e.g. only users with high DPI multi- > screen setups) > - configurable encouragement of users to contribute (ie. after X starts > and/or Y hours of usage, repeated after Z months, suggest the user to > participate if they aren't already doing so). > - a management and analytic tool that allows you to manage products and > survey campaigns, and view recorded data using configurable aggregations > - the entire thing works without unique user ids. Fingerprinting can still > be an issue on too small user sets and/or when using too much detail in the > data. - by default all of this is opt-in of course, although technically > the API doesn't prevent applications to change this > - it can deal with multiple products, each product can have different data > sources and survey campaigns Haven't read much of the code yet, so I'll ask some stuff. Is there a way for the user to see (locally) the data he has sent to the servers? Is there a way for the user to remove the data he has sent to the servers? Guess not since otherwise we would be able to do a 1:1 mapping Do we have some way in the server to protect us from people trying to inject "fake/wrong" data? I see you protected the data on the server with a user/password. If the data is really anonymous do we really need user/password ? And if we actually do need need user/password is there a way to restrict which data can a user see (i.e. configure that I can see Okular's data but not Krita's?). Thanks for working on this :) Cheers, Albert > > Technically, this consists of the following parts: > - a library that goes into the target application, backward compatible all > the way to Qt4.8/MSVC2010 (needed for my GammaRay use-case), depending only > on QtGui > - a library with the reference widgets, also with extended backward > compatibility > - the server, written in PHP5 and supporting sqlite/mysql/postgresql. Not > the most fun technology, but that stuff is available almost anywhere, and > easy to deploy and maintain > - the management tool, recent Qt5/recent C++, using QtCharts for the data > analysis > - a command line tool for data import/export, useful for eg. automated > backups > > All of this is LGPLv2+ licensed. > > Feedback obviously very welcome, in particular around privacy concerns, or > reasons that would make you enable/disable such a feature. > > Regards, > Volker
Re: Application usage statistics and targeted user surveys
El diumenge, 23 d’abril de 2017, a les 12:52:57 CEST, Volker Krause va
escriure:
> Hi,
>
> we have talked about the above topics a couple of times in the past, from
> what I remember usually agreeing it would be nice to have some more
> statistical information about our users, so we know what our applications
> are used for, and to measure impact of changes. Similarly, it would be nice
> to be able to actually ask our users questions without statistical bias by
> using out-of-band channels like blogs or social media. This can be
> obviously addressed by adding this into application code, but that raises
> some valid privacy concerns.
>
> Wanting this for GammaRay I attempted to implement a generic framework for
> this, with the goal to make this fully transparent, and give the user full
> control over what data is shared, and how often they want to participate in
> surveys, ie. make this solid enough on the privacy side that even I would
> enable it myself. You'll find the code in Git (kde:kuserfeedback).
I needed the attached patch for it to build properly on my system.
Cheers,
Albert
>
> Feature-wise it so far contains:
> - a set of built-in data sources (app version, Qt version, platform,
> application usage time, screen setup, etc) that applications can choose to
> enable
> - generic data sources for tracking the time ratio a Q_PROPERTY has a
> specific value, allowing to track e.g. which application view is used how
> much - the ability to add custom/application-specific data sources
> - reference widgets for customizing what data you want to share, and showing
> exactly what that means, in human readable translated text and if you
> insists also all the way down to the raw JSON sent to the server.
> - survey targeting using simple C++/JS-like expressions that can access all
> the data sources (ie. you can target e.g. only users with high DPI multi-
> screen setups)
> - configurable encouragement of users to contribute (ie. after X starts
> and/or Y hours of usage, repeated after Z months, suggest the user to
> participate if they aren't already doing so).
> - a management and analytic tool that allows you to manage products and
> survey campaigns, and view recorded data using configurable aggregations
> - the entire thing works without unique user ids. Fingerprinting can still
> be an issue on too small user sets and/or when using too much detail in the
> data. - by default all of this is opt-in of course, although technically
> the API doesn't prevent applications to change this
> - it can deal with multiple products, each product can have different data
> sources and survey campaigns
>
> Technically, this consists of the following parts:
> - a library that goes into the target application, backward compatible all
> the way to Qt4.8/MSVC2010 (needed for my GammaRay use-case), depending only
> on QtGui
> - a library with the reference widgets, also with extended backward
> compatibility
> - the server, written in PHP5 and supporting sqlite/mysql/postgresql. Not
> the most fun technology, but that stuff is available almost anywhere, and
> easy to deploy and maintain
> - the management tool, recent Qt5/recent C++, using QtCharts for the data
> analysis
> - a command line tool for data import/export, useful for eg. automated
> backups
>
> All of this is LGPLv2+ licensed.
>
> Feedback obviously very welcome, in particular around privacy concerns, or
> reasons that would make you enable/disable such a feature.
>
> Regards,
> Volker
diff --git a/docs/CMakeLists.txt b/docs/CMakeLists.txt
index 0031761..dda6d4f 100644
--- a/docs/CMakeLists.txt
+++ b/docs/CMakeLists.txt
@@ -1,7 +1,8 @@
-find_program(QDOC_EXECUTABLE qdoc)
-
query_qmake(QT_INSTALL_DOCS "QT_INSTALL_DOCS")
query_qmake(QT_INSTALL_DATA "QT_INSTALL_DATA")
+query_qmake(QT_INSTALL_BINS "QT_INSTALL_BINS")
+
+find_program(QDOC_EXECUTABLE qdoc HINTS ${QT_INSTALL_BINS})
find_file(QDOC_TEMPLATE global/qt-html-templates-offline.qdocconf
HINTS ${QT_INSTALL_DOCS}
Re: kdereview - xdg-desktop-portal-kde
El divendres, 21 d’abril de 2017, a les 8:10:36 CEST, Jan Grulich va escriure: > Hi, > > I would like to request review of xdg-desktop-portal-kde [1]. We would like > to make it part of Plasma releases, see [2]. > > What is xdg-desktop-portal-kde: > It's a KDE implementation of Flatpak portals backend [3], currently with > support of AppChooser, FileChooser, Notification and Print portals. > > One mentioned issue on plasma-devel mailing list was usage of Qt's private > print API. This will most likely go away if I find out it's useless, > otherwise I'll have to keep it as it's used to set CUPS properties which > are not available to the outside world. Since you have copied some code from Okular maybe you can add some other (C) there other than RedHat's? What about the unusued QVariantMap in the print.cpp file? What are you supposed to return there? I've no idea how to use this so can't really test it :/ Cheers, Albert > > [1] - https://cgit.kde.org/xdg-desktop-portal-kde.git/ > [2] - https://mail.kde.org/pipermail/plasma-devel/2017-April/069506.html > [3] - > http://flatpak.org/xdg-desktop-portal/portal-docs.html#idm140258860052032 > > Regards, > Jan
