The usage statistics [kactivities, baloo, ktp, plasma]

[Vishesh Handa]

On Tue, Oct 21, 2014 at 7:00 PM, Ivan Čukić <ivan.cukic at gmail.com> wrote:

> > Recently used applications across the entire system.
>>
>> Potential Use case: I can only see this being used in KRunner when
>> searching for applications.
>>
>
> And Kickoff etc. (not only when searching apps)
>

So Kickoff would be showing both the most frequently used and the automatic
favorite applications?


>
>>
>> > Recently used documents across the entire system.
>>
>> We already have KRecentDocuments which stores .desktop files in
>> ~/.local/share/RecentDocuments. It's integrated in our file dialog as well.
>> Though I do actually doubt the usefulness of this list. How do want to
>> improve this?
>>
>
> Again, Kickoff (and others) like to show a list of recent documents.
>

Who else?


>
> One of the reasons I started working on usage tracking and scoring is
> because of the 'usefulness' of KRecentDocuments.  I always found it
> irrelevant because it usually shows at most one useful item. If it took
> into the account the scores, it would become much more useful than it is
> now (IMO).
>

Could you perhaps talk about possible workflows and how this would be
displayed to the user? I'm still quite skeptical about how useful a global
recently used files list actually is.

I've always found the list of recent documents quite irrelevant as well.


> > Most frequently used (high usage score) documents across the entire
>> system.
>>
>> I'm not too sure where this would be used.
>>
>
> See above.
>

I would like workflow and use cases for this as well.


>
> > Recently used documents by $application.
>>
>> Definitely useful. Each application currently stores this in their config
>> file. What were you planning on adding?
>>
>> > Most used (high usage score) documents by $application.
>>
>> I'm not too sure if anyone but the $application would use this list.
>>
>> Perhaps it's application's decision if they want such a feature and they
>> can probably implement it quite easily. For example - I'm not too sure
>> about a videos applications wanting the most recently viewed videos.
>>
>
> The point is to have a generic thing that supports different variations on
> the same tune. That is, a few different things need to know what was opened
> and when, and then you get a lot of side things that could benefit from it
> as well.
>

Such as?


> In this case, yes, every application does implement its recent documents
> mechanism and could implement the high scored ones etc. But, in that
> case,the workspace would have no idea about any of those - the tasks applet
> (or the launchers) would not be able to show the documents for applications
> etc.
>

Questions that are coming to my mind -
* Do we need the shell/kactivities to know about this information?
* Does this need to be stored in a global database or applications continue
using their config files and we just make a standard format?
* How would this information be displayed to the user? You mentioned the
launcher. Can you give me an example?

(p.s. One of the things I forgot to write before - the same mechanism could
> be used as a base for replacing the xsession protocol which I guess will go
> away along with the X11)
>
>
>> > Metadata for the recently/most used documents, so they can e.g. be
>> grouped by type.
>>
>> * I'm not too sure what you mean. We already have a recently used
>> documents list, and this can be grouped based on type
>> * Where would this be used?
>>
>
> This one was also requested by Eike.
>
> From my POV, one use-case would be applications that open different things
> like KDevelop having sessions and files. So a mimetype could be used to
> filter out what exactly they want to show etc.
>

So basically a filter on top of the global list of recently used documents?

>
>
>> > Application Launching Interface (ALI) search history.
>>
>> * You mean like the krunner search history that was there in KDE4?
>>
>
> For example.
>

Would this need to be a part of kactivities or can we just add this in
krunner?

-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20141021/286cded1/attachment.html>