> 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)? > > Seif Lotfy wrote: > 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
What are the current prospects of overhauling this piece of code to make use of zeitgeist, etc? If it's not going to happen "soon", then I would like to still nominate this change for inclusion. - Andriy ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105112/#review14293 ----------------------------------------------------------- On July 4, 2012, 7:57 a.m., Andriy Gapon wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105112/ > ----------------------------------------------------------- > > (Updated July 4, 2012, 7:57 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel