On Tue, Sep 18, 2012 at 3:38 PM, Aleix Pol <[email protected]> wrote: > On Mon, Sep 17, 2012 at 8:17 PM, David Edmundson > <[email protected]> wrote: >> Aleix has been working super hard on libkpeople at the moment. >> >> I'd like to encourage people to have a play, and make sure everything >> works an is stable before we progress too much. >> >> You will need: >> a working nepomuk >> kde:ktp-nepomuk-service >> kde:libkpeople (branch apol/queries) >> >> There's some examples in the examples folder. >> Aleix, could you explain what all the different examples do? > Yes, sure. We have 3 examples right now: > - lovelypeople: a QTreeView+PersonsModel, not much else > - sweetpeople: a QML contact list that uses PersonsModel and tries to > display all the information we have available. > - niceperson: a QWidget where PersonData puts the information and > actions it has available. > > To add some background here, PersonData would be the information for 1 > person alone and PersonsModel is a model that exposes all the people > in the system. PersonData was created so that we don't need to query > for everyone in the system in case we're only interested in 1 person. > >> >> The plan is to hack everything together and then work out what >> works/needs changing instead of constantly redesigning things that's >> been happening for years. I think quite a lot may end up changing, >> there's a few things in the API I'm currently questioning but the best >> way to find out is to just hack things and see. >> >> Documenting an IRC chat this week, the tasks are: >> - Make the CL use kpeople (mck182?) >> - Make the text-ui use kpeople (d_ed) >> - Make an address book based on kpeople (mck182) >> - UI for contact merging >> - Make KMail show contact onlineness/other stored information >> (somehow assigned to me) >> >> In addition, and probably a priority is I want a a mockup of the show >> info dialog currently in the CL and show how how all the contact >> information from all the resources will be represented. We need a >> marketing hook to convince sceptics (like me) why this whole database >> shenanigans is a good idea, and what additional information it can >> show. >> >> All kpeople dependencies to existing apps will take place solely in >> branches. KTp master is _not_ too be touched until everything is >> deemed to be working. Other modifications and preparations (such as >> phasing out use of ContactItem* etc) can happen in master. >> >> Having said all this, priority for everyone should still be anything >> in the 0.5.1 milestone, this should contain everything that _needs_ to >> be fixed before the Kubuntu release. >> >> Dave >> _______________________________________________ >> KDE-Telepathy mailing list >> [email protected] >> https://mail.kde.org/mailman/listinfo/kde-telepathy > > > :) thanks david for taking care about the KTP side. > > And please remember to poke me as soon as I can help by putting > KPeople in shape :). > Also if anyone is interested in doing a similar work for > Kontact/KDEPIM that would be really appreciated. > > Cheers! > Aleix
Just as an update: I've just merged apol/queries to master, I'll start looking into the integration with Homerun [1]. This way we'll get a wider scope of what's needed in the framework. Cheers! Aleix [1] https://projects.kde.org/projects/playground/base/homerun _______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
