<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 13, 2014 at 6:59 PM, Ivan Čukić <span dir="ltr"><<a href="mailto:ivan.cukic@kde.org" target="_blank">ivan.cukic@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi all,<br>
<br>
As promised, starting a discussion on how we can use the usage statistics<br>
gathered by kactivitymanagerd (kamd in the rest of the text). And the design<br>
of the API to cover the use-cases.<br>
<br>
The point is to discuss all of this and put the summaries on the etherpad page<br>
at <a href="https://notes.kde.org/p/KActivities_Usage_Statistics" target="_blank">https://notes.kde.org/p/KActivities_Usage_Statistics</a><br>
<br>
<br>
1. Use-cases<br>
=========<br>
<br>
The main ideas I had while developing Lancelot (some overlap with those that<br>
Eike and David have):<br>
<br>
 - Automatically deduced favourite applications for the users that didn't set<br>
them up (not important whether they actually end up in the favourites section,<br>
or are used just for sorting in krunner or something).<br>
 - The same as the above, but for documents (per-application, and global) or<br>
contacts or ...</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 - Replacing the 'recent documents' with something more meaningful (kinda a<br>
subset of the previous item)<br>
 - Tasks applet and launchers could show the list of important (or recent)<br>
documents opened in a specific application.<br></blockquote><div><br></div><div><div><div>One use case that we might want to consider is including email frequency when sorting contacts.<br></div><div><br></div><div>What makes this very different from the rest is that the length of event doesn't really apply. I tend to write an email then fill in the address last, so kmail couldn't give accurate stats if it tried. and the length of time I spent typing might not have any impact. </div><div><br></div></div><div>I'm a bit skeptical of the time tracking rather than usage tracking in general, if a user opens something 10 times and closes that quickly, it's more important to list that in favourites than something a user only opens once and leaves open. We might need to have an API that doesn't pass a wID and just inserts an arbitrary time and/or a way to not put any weight on the time interval in the querying API.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 - ** more advanced ** Deducing which things belong to each other based on the<br>
fact they have been often used together and similar.<br>
<br></blockquote><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
2. What is currently there<br>
=================<br>
<br>
(mostly copied from the mail I sent Eike some time ago)<br>
<br>
- It supports tracking for open/close, focus-in/out, modified and accessed<br>
events (from the API side, handled by KActivities::ResourceInstance class in a<br>
pretty RAII manner :) )<br>
- Every event has the activity in which it occurred (usedActivity field),<br>
application that triggered the event (initiatingAgent) and the timestamps (and<br>
the URL of the thing - targettedResource - a document, a contact, ...). The<br>
names are a bit cumbersome, they are taken from the ontology that was designed<br>
for this purpose. You can write Agent, Activity, Resource for the sake of<br>
brevity.<br>
- Apart from that, it also keeps the scores for the things.<br>
<br>
Vishesh asked for the formula for the scoring - see appendix 1.<br>
<br>
Applications that supported this in 4.x were (I'm probably missing a few):<br>
Dolphin, Gwenview, Calligra (modulo Kexi), Okular, Kate, KWrite and Vim in<br>
konsole. I have no idea whether the patches remained in Qt5 ports.<br>
<br></blockquote><div>Gwenview code remained. Though it's purely logging and not using any of it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
3. What will be needed<br>
================<br>
<br>
Integration with baloo. It will require patches on both sides if we are to<br>
support all the use-cases without cross-queries. We will need accessible file<br>
types via sqlite (on baloo side) and baloo identifiers or something on kamd<br>
side.<br>
<br>
One of the things that I think will be needed is some kind of additional<br>
payload that the applications will be able to store alongside the resource<br>
event. We'll see after we collect the use-cases.<br>
<br>
<br>
4. Reading API<br>
===========<br>
<br>
This needs to be designed. I would not be surprised if the API ends up being<br>
similar to baloo's querying system since it seems we will have quite a diverse<br>
set of use-cases. Although, it should provide a proper live data model for the<br>
results.<br>
<br>
<br>
Appendix 1: Formula for the resource scoring:<br>
===============================</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
LaTeX formatted:<br>
    S = \sum _{i = 1} ^ n<br>
        e^{-d_i} e^{k_i \log(l_i)}<br>
<br>
Haskell-like formatted, whichever you find easier to read :)<br>
    sum [<br>
        exp (-di) * exp ( ki * log li )     | i <- [1..n]<br>
    ]<br>
<br>
where d_i is the time that passed since the i-th event, k_i coefficient<br>
depending on the type of the event, l_i length of the event (time distance<br>
between open and close for example, or focus in and out)<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It can be rewritten to look prettier (exp log = id and so on), but this<br>
conveys the meaning in a nicer way by separating the terms according to their<br>
meaning.<br>
<br></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The main ideas behind the formula are:<br>
 - score degrades with the time, so if a document was kept open in okular for<br>
an hour yesterday, it will have a significantly higher score than a document<br>
that was kept open for a whole day a year ago;<br>
 - different events have different meanings;<br>
 - event time interval is measured on a logarithmic scale, so that there is a<br>
greater difference between 1hr and 2hrs, than between 11hrs and 12hrs;<br>
 - can be calculated quickly by only processing new events since the last<br>
score update.<br>
<span class=""><font color="#888888"><br>
<br>
--<br>
Cheerio,<br>
Ivan<br>
<br>
<br>
KDE, ivan.cukic at <a href="http://kde.org" target="_blank">kde.org</a>, <a href="http://ivan.fomentgroup.org/" target="_blank">http://ivan.fomentgroup.org/</a><br>
gpg key id: 850B6F76, <a href="http://keyserver.pgp.com" target="_blank">keyserver.pgp.com</a><br>
_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
</font></span></blockquote></div><br></div></div>