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 > [email protected] > https://mail.kde.org/mailman/listinfo/kde-telepathy -- [email protected] | Associate Software Engineer / BaseOS / KDE, Qt GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
