Models Moving Plan

[David Edmundson]

All the roles (that we use)  have been written into a table here:
http://community.kde.org/KTp/Tasks/ModelRoles#Old_Roles

I have written "Kill it!" next to several of them, these roles will
die (and break any code that did use them). Any of the roles not in
this list will also die (as nothing used them anyway). Please check
this, as there were some I had no idea what they could be for.

There is also a section "New Roles" if there are any roles that you
want adding to the model it'll be easier if we do it now. Just add a
text description. In a day or two I'll convert this into a real enum
as types.h and convert any code.

David

On Thu, Jan 24, 2013 at 10:29 AM, Daniel Vrátil <dvratil at redhat.com> wrote:
> On Wednesday 23 of January 2013 13:39:19 David Edmundson wrote:
>> We are about to enter phase 6
>
> Hooray!
>
>>
>> "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?
>
> I haven't seen the code, but I assume the TranslationIdentityProxy is a
> QAbstractProxyModel - if so, I believe it's a good solution. That's what proxy
> models are for! And honestly I can't think of any (other && better) 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?
>
> +1
>
> Do you want to move them from ContactsModel scope, or do you want to preserve
> it for compatibility?
>
>>
>> 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?
>
> The new model completely ignores AutomaticPresenceRole, CurrentPresenceRole
> and RequestedPResenceRole - I can't imagine any use for these information
> anyway, so these could probably go.
>
> MediaCallCapabilityRole, UpgradeCallCapabilityRole,
> DesktopSharingCapabilityRole and SSHContactCapabilityRole are ignored too, but
> I don't know whether that's deliberate (we don't need/want to expose these),
> or just forgotten.
>
>>
>> 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?
>
> I'd keep both versions. PresenceRole is useful when you need to pass or store
> Tp::Presence object somewhere. The individual properties roles are useful when
> using our models in QML - firstly because QML does not cope will with shared
> pointers, secondly because Tp::Presence is not a QObject, so it's very hard
> (impossible?) to access it's properties directly from QML.
>
>
> Dan
>
>> _______________________________________________
>> KDE-Telepathy mailing list
>> KDE-Telepathy at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-telepathy
> --
> dvratil at redhat.com | Associate Software Engineer / BaseOS / KDE, Qt
> GPG Key: 0xC59D614F6F4AE348
> Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy
>