Review Request: kickoff: save recent applications list on every change to it
Seif Lotfy
seif at lotfy.com
Thu May 31 21:18:24 UTC 2012
> On May 31, 2012, 10:09 a.m., Aaron J. Seigo wrote:
> > the real fubar here is that it stores this information internally in its own config file. this really ought to be stored/retrieved from nepomuk and/or zeitgeist.
> >
> > i've cc'd Trever on this because he may have something to say about that as well.
>
> Trever Fischer wrote:
> I actually just recently patched Dragon to do so, and it took very few lines: http://quickgit.kde.org/index.php?p=dragon.git&a=commitdiff&h=92fb6296e424dc829e0c5cc541aa3581856d2098
>
> Since Kickoff uses QAbstractItemModels, switching things to use a QZeitgeist::LogModel should be trivial. Alternatively, implementing the RecentApplications class to use Zeitgeist can be trivial as well, and would seem like the easiest way to do things.
>
> Aaron J. Seigo wrote:
> if we could dump RecentApplications that'd be great. there's not much reason to go through a local class just to get to another library (qzeitgeist) class. then the LogModel can be used in the RecentlyUsedModel ..
>
> in fact, if KRecentDocument in kdelibs/kio/kfile/ were made to use zeitgeist, i bet we could just drop the RecentlyUsedModel altogether, or at worst have it as a thin layer around LogModel (don't know what LogModel provides, so I can't really offer a concrete suggestion there). that sounds like frameworks 5 work, though, so we'll have to just hold off on that for kickoff .. but would seem to be the natural progression and something that could implemented immediately in the frameworks branch in any case...
>
> Trever Fischer wrote:
> logmodel.h: http://quickgit.kde.org/index.php?p=libqzeitgeist.git&a=blob&h=2ef6bfac0ab917ed5508da64b3a9d1a9290e65e6&hb=a58d1caaa953b514b7bd1697c44aebf75b11829d&f=src%2Flogmodel.h
>
> It provides a bunch of shortcuts for access to the underlying event object data, or you can access the event in its entirety.
>
> What it doesn't provide that the recentlyusedmodel provides is the immediate ability to remove events. You'd need to grab the event and then ask a Log object to delete it from the database. I am considering adding that API to the 0.10 release.
>
> Ivan Čukić wrote:
> Another thing for these types of models that we *need* to start adding is the support for different results based on the activity.
>
> Has Zeitgeist moved in that direction as promised before (in Randa)?
This is supported. Just attach the id of the activity to the event.origin. You can then query Zeitgeist with event.origin set to the activity id and it will return only results based on events that happened in that activity
- Seif
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105112/#review14293
-----------------------------------------------------------
On May 31, 2012, 10:08 a.m., Andriy Gapon wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105112/
> -----------------------------------------------------------
>
> (Updated May 31, 2012, 10:08 a.m.)
>
>
> Review request for Plasma and Trever Fischer.
>
>
> Description
> -------
>
> Currently recent applications list in kickoff is saved only when kickoff gracefully exits. This could be a minor annoyance when X/KDE/plasma crashes. I think that saving the list on every update to it should be a good idea. It should be a low overhead too, because the list changes only when a user launches an application via KDE.
>
>
> This addresses bug 206511.
> http://bugs.kde.org/show_bug.cgi?id=206511
>
>
> Diffs
> -----
>
> plasma/desktop/applets/kickoff/core/recentapplications.cpp 3e05389
>
> Diff: http://git.reviewboard.kde.org/r/105112/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Andriy Gapon
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120531/4899e932/attachment.html>
More information about the Plasma-devel
mailing list