On Mon, Jan 21, 2013 at 7:54 AM, Martin Klapetek wrote: > Hey everyone, > Firstly, thanks for writing this. > here's how it currently looks with our metacontacts. KPeople is fully usable > now. The API as well as the code needs some cleanup, but right now > everything we want is there and working. > > Overview: > * grouping/ungrouping contacts (even with non-IM contacts) > * starting chats/audio/video > * getting detailed info about persons > > What's missing > * editing stuff > > - this is very easy in terms of code, but becomes quite complex in the > bigger picture; we need writeback services in Nepomuk in order for this to > work sensibly. Right now we're getting data from Akonadi and Telepathy. If > we change say a nickname in contact list (with kpeople), this change should > be written back to Telepathy. Not many clients support changing names on rosters.. xmpp does.. but GTalk and Facebook won't support it. I'd be happy to not see this feature. > Same goes for Akonadi of course. Agreed, we also need to be writing in the IM address into Akonadi address books. >Otherwise > we're in a state where two data providers have inconsistent data and that > can lead to problems. OR we can do all changes only locally in Nepomuk. > What's bad about that is that the changes will be kept only locally. On the > other hand, the grouping into metacontacts will also be just local. Vishesh, > what's your take on this? > > * filtering & sorting > > - we have a plan with David to have shared roles between models, so we can > switch models on the fly. Once we achieve that, we'll reuse the current > (awesome) proxy filter > > * starting actions through KTp infrastructure > > - this is again so we can just switch the models on the fly and thus reuse > all the existing KTp code paths. However one tiny issue is that we don't > have account info accessible in the main KPeople model. I'm thinking > I'm thinking you forgot to finish that sentence :) and are you sure we don't have an account? We set a imAccountUri and that account "object" imAccount.addProperty(Nepomuk2::Vocabulary::Telepathy::accountIdentifier(), path); > * grouping > > - should be fairly easy, the groups are present in Nepomuk, just not used > > * contact's offline presence > > - for the contact list to work properly with kpeople, one needs to have the > ktp-nepomuk-feeder running ALL the time. Once it's down, we're screwed. > Currently there's a different problem though - when the service shuts down > (logout or reboot for example), it leaves all the presences in Nepomuk in > whatever state they were. This means when you relogin and run the contact > list, all the contacts have wrong presences until the feeder kicks in and > puts correct data into Nepomuk. If the feeder for whatever reason won't > start, the user is left with random invalid presences. It could write > offline presence while being destroyed, but that would need to be > synchronous job which can take some time, which means delaying > reboot/logout/whatever for no apparent/visible reason to the user. We were > talking if we could reuse KTp presences as we have them available in almost > realtime, but that means combining two models (where one queries the other) > and I don't like that very much. > "this means combining two models". I agree that would be convoluted and rather mental. What I don't agree with is that this means combining two models as the only option: This is how I imagined I would do it. KPersonModel { //all contact stuff, except presence, caps, returns Tp::UnknownPresence for presence role. data() rowCount() } KPeopleModelWithPresence { data() { if (role== presenceRole) { //get contact id from index (from other model), look up presence from hash } // this will also return ContactRole and AccountRole, so actions in KTp automatically work. } QMap > } This could happen either in the subclass, or an identityProxy model OR like TpQt has features that you pass to a constructor of the model, so it's all in the same class. We then strip presence/caps from the feeder. This keeps things lightweight for people who don't care about presences, in a design that I think is quite simple. It fixes all known bugs, (including one not listed.. you don't record streamtube/dbus tube caps) And it removes load on the feeder so new accounts will be imported quicker. We then get into an argument over which design is cleaner. - All the information is in one place, two sources is more complex vs - The information is already available via dbus, and we have a fantastic library to get it. Proxying it through a database for no reason is more complex > * good looking delegate for metacontacts > > - right now I'm simply painting the presences in a row with no indication of > "this is a metacontact" (except the multiple presences on one row). > Double-clicking the item expands it and shows all the individual contacts. > Ideas/mockups welcome. > > * good startup time > > - currently we're at ~3 secs before contact list shows up with ~800 > contacts. I'll investigate where's the holdup and see what we can do about > it. > > > If we can get at least the last 4 tasks sorted (plus filtering), I'm very > happy to ship it with 0.6 as a tech-preview. The metacontacts users create > in this should prevail once we get the full thing released. > I like this "0.6 as a tech-preview" idea. The hard part is communicating with packagers and users. > The development is happening in branches - kde:libkpeople - > mklapetek/toplevel_contacts and kde:ktp-contact-list - mklapetek/kpeople. > I'll spend this week on cleaning up kpeople and tuning the performance. > > If you'd like to help out, let me know and I'll point out exactly what needs > doing. > > Cheers > -- > Martin Klapetek | KDE Developer > > _______________________________________________ > KDE-Telepathy mailing list > KDE-Telepathy@kde.org > https://mail.kde.org/mailman/listinfo/kde-telepathy > _______________________________________________ KDE-Telepathy mailing list KDE-Telepathy@kde.org https://mail.kde.org/mailman/listinfo/kde-telepathy