[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-telepathy
Subject: Re: Models Moving Plan
From: Daniel =?ISO-8859-1?Q?Vr=E1til?= <dvratil () redhat ! com>
Date: 2013-01-24 10:29:38
Message-ID: 1828513.lvOqUJXErW () odin
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
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@kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy
--
dvratil@redhat.com | Associate Software Engineer / BaseOS / KDE, Qt
GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
["signature.asc" (application/pgp-signature)]
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic