Models Moving Plan

[Daniel Vrátil]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-telepathy/attachments/20130124/ddab9990/attachment.sig>