[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-telepathy
Subject:    Re: Models Moving Plan
From:       David Edmundson <david () davidedmundson ! co ! uk>
Date:       2013-01-25 0:42:56
Message-ID: CAGeFrHCGrTmM2hxRoJYGFiVeBbKkw13jVv6FYF7Z3MeLtpO6Vg () mail ! gmail ! com
[Download RAW message or body]

On Thu, Jan 24, 2013 at 11:20 PM, Aleix Pol <aleixpol@kde.org> wrote:
> On Wed, Jan 23, 2013 at 2:39 PM, David Edmundson
> <david@davidedmundson.co.uk> wrote:
>>
>> We are about to enter phase 6
>>
>> "6 - Share roles enum and names between ContactListModel (ours) and the
>> one from KPeople"
>>
>> Question 1:
>>
>> Mck182 has written a translationIdentityProxy that converts
>> PersonsRoles to KTp roles.
>> This allows KPeople to do it's own thing, whilst co-existing with KTp
>> code.
>>
>> Is this a quick hack, or a good medium-long term solution?
>>
>> Question 2:
>>
>> Roles are currently in the old class ContactsModel, I propose making a
>> KTp types.h file and having all roles as an enum there. Is this a good
>> idea?
>>
>> Question 3:
>>
>> There are a lot of roles that we don't need in the old model. I want
>> this list reduced to what we actually need and use, how should we go
>> about doing this?
>>
>> Question 4:
>>
>> Currently in the model we sometimes expose thing in mulltiple ways, In
>> particular presence. There are 5 roles for presence currently:
>>
>>         PresenceRole,   ( a Tp::Presence object)
>>         PresenceIconRole, (icon for this presence type)
>>         PresenceStatusRole, (string)
>>         PresenceTypeRole, (presence type enum)
>>         PresenceMessageRole, (string)
>>
>> Is this a bad thing? Given models are for portability should we drop
>> the PresenceRole? Should we drop all other 4 and leave the logic up to
>> the UI?
>> _______________________________________________
>> KDE-Telepathy mailing list
>> KDE-Telepathy@kde.org
>> https://mail.kde.org/mailman/listinfo/kde-telepathy
>
>
> Q1/Q2:
> I like using the identity model in the KTP side. I'd say that we should aim
> that some software using KPeople, only should link to KPeople. Adding a
> ktptypes.h include would add a weird dependency outside. I don't think it
> makes sense to have such an include within ktp, but it could be useful.
>
I agree with this as a long term goal.
I think in the not to distant future I can see ktp-common-internals
relying on kpeople and I don't want an infinite loop. Recent changes
are going to make that somewhat harder...

> Q3/Q4:
> That breaks ABI, so it shouldn't happen. If you can break it I'd say it
> should be for a more important reason than that.
> Is that a big problem for the ContactsModel?
>
We've broken a lot of the ABI already :). I'm about to delete all the
models that were in 0.5.
We don't have public headers, and have never claimed to be stable.

When this was started we didn't know what we needed, and we imporrted
some models from Yell that were a bit "specialist". They weren't
namespaced properly, so we needed to break the API (and therefore ABI)
anyway to put them into KTp at some point. May as well do it all in
one go.

I want to be in a situation where going on from 0.6 we have a solid
API that isn't going to change much for a long time. This means
removing all the rubbish so that when we do go stable, it's something
clean, finished and ready.. not half full of rotting code already.
There is a plan... honest!

Dave

> Hope this helps...
> Aleix
>
> _______________________________________________
> 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
[prev in list] [next in list] [prev in thread] [next in thread]