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