On Tue, Oct 21, 2014 at 7:00 PM, Ivan Čukić <ivan.cu...@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
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
