KPersons again

[Aleix Pol]

On Tue, Sep 18, 2012 at 3:38 PM, Aleix Pol <aleixpol at kde.org> wrote:
> On Mon, Sep 17, 2012 at 8:17 PM, David Edmundson
> <david at davidedmundson.co.uk> 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
>> KDE-Telepathy at kde.org
>> 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