Pinned people change overtime

[David Edmundson]

An update on this for the mailing list, because it's quite interesting.
There's a "new" pitfall in TpQt programming to watch out for.

Everyone was sort-of right.

My original comment "if you have a contact, and the connection goes down,
the data stays the same and never changes" is true. You can access id(),
avatar(), presence() etc.

Even the targetHandle() remains the same... and this is the cause of the
problem.

The targetHandle is an integer ID used to keep track of a contact, this is
NOT persistent between connections. TargetHandle is normally completely
internal to TpQt and we never use it so it's normally not a problem.
account->startChat() however does use this handle. This handle now refers
to a different contact, and we have the problem Aleix described.

If this code read account->ensureTextChat(contact->id()); this would
actually work - and we can ship that if I don't get my new patch done in
time.
This is why we don't have the same problem in the text-ui when we do a
reconnection, as we happen to use the the channel->targetID();

We still want to fix the model so that it gets the latest contact,

Summary:
 - Sorry to Aleix and George K for not believing you :)
 - Everyone should be very careful when using contacts for which the
connection has dropped, especially if a new connection comes back.
 - KTp::ContactPtr has a nice invalidated() signal which is useful.
 - Using KTp::GlobalContactManager implicitly guards against this as the
accountForContact() will fail if the contact's connection is gone.
 - I'd like to change TpQt to set the handle to -1 when the
connectionManager gets outdated. We already have an open bug to set the
clientTypes() to empty when this happens. So this should be a trivial
addition.

On Tue, Feb 19, 2013 at 11:31 PM, Aleix Pol <aleixpol at kde.org> wrote:

> no, I'll report it later, I'll try not to forget :)
>
> On Tue, Feb 19, 2013 at 2:40 PM, David Edmundson <
> david at davidedmundson.co.uk> wrote:
>
>> BTW, is there a bug report on this?
>>
>>
>> On Tue, Feb 19, 2013 at 1:21 PM, David Edmundson <
>> david at davidedmundson.co.uk> wrote:
>>
>>>
>>>
>>> On Tue, Feb 19, 2013 at 12:31 PM, George Kiagiadakis <
>>> kiagiadakis.george at gmail.com> wrote:
>>>
>>>> On Tue, Feb 19, 2013 at 2:24 PM, Aleix Pol <aleixpol at kde.org> wrote:
>>>> > Hi,
>>>> > I'm having a bit of a weird problem, since it's a bit long to
>>>> explain, I
>>>> > figured it would be better to explain it over the mailing list.
>>>> >
>>>> > As you'll know, we have this pinned contacts in the chat plasmoid. It
>>>> stores
>>>> > a KTP::ContactPtr and when I click the button I start a chat with this
>>>> > contact.
>>>> > Now the problem that I'm having is that when using it in my system I
>>>> found
>>>> > out that, after putting my laptop on suspend mode, when I click the
>>>> pinned
>>>> > contact a chat gets started with someone else.
>>>> >
>>>> > Do you think it could be that there's no identity integrity after an
>>>> > offline/online cycle?
>>>> > How do you think this should be fixed?
>>>> >
>>>>
>>>> I think you shouldn't be storing ContactPtr. Contact objects are part
>>>> of a certain Connection, so when the connection changes, weird things
>>>> are likely to happen. You should store the contact id instead.
>>>>
>>>
>>> A contact object should not be changing what it represents when a
>>> connection resets.
>>> I don't think that is the case, otherwise we'd be getting a lot more
>>> errors elsewhere. Text-ui retains a ContactPtr after going offline. It
>>> remains valid.
>>>
>>> Generally after a reset the original Tp::ContactPtr becomes useless; any
>>> calls to manager() return 0 and it stops getting updated but it doesn't
>>> turn into a different contact.
>>>
>>>  I would suspect the problem is in the
>>> pinned-contacts-model/conversations-model before investigating elsewhere.
>>> That entire area has been under a lot of development on top of experimental
>>> code and needs a really good tidy up.
>>>
>>> David
>>>
>>>
>>>
>>
>> _______________________________________________
>> KDE-Telepathy mailing list
>> KDE-Telepathy at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-telepathy
>>
>>
>
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-telepathy/attachments/20130303/0741c115/attachment.html>