Review Request: New ContactsListModel

[Daniele Elmo Domenichelli]

> On Jan. 3, 2013, 11:59 a.m., Daniele Elmo Domenichelli wrote:
> > KTp/contact.h, lines 38-43
> > <http://git.reviewboard.kde.org/r/107629/diff/2/?file=100417#file100417line38>
> >
> >     What about a
> >     class KTp::ContactCapabilities : public Tp:ContactCapabilities {...};
> >     and a method
> >     KTp::ContactCapabilities capabilities() const;
> >     instead?
> >     
> >     This would make it more coherent with the Tp::Contact class and with the presence method returning a KTp::Presence instead of a Tp::Presence
> 
> David Edmundson wrote:
>     The thing is this is a mixture of our caps and the other person's caps.
>     
>     Therefore I don't think effectively overriding Tp::Contact::capabilities() is a good approach.
>     
>     However making this as a method that returns a struct extending Tp::Capabilities is frickin' genius.
>     perhaps as KTp::Contact::commonCapabilities() ?

Hmm... What about using "capabilities" for what one side can do and "abilities" (instead of commonCapabilities) for what can actually be done? (Actually I don't know if there is a difference in English, but for some reason it sounds good to me :P Or if you can find a better word for that...). Technically is not just "common capabilities", since we should check for capabilities on both side _and_ that the handler is available (at least I think this is what we do for desktop sharing).

So, perhaps you can have both...

1) Tp::ContactCapabilities capabilities() can be a public method that internally uses the hack (and should be made virtual in Tp::Contact)
2) a class KTp::ContactAbilities : public Tp::ContactCapabilities and an abilities() method that does the magic


- Daniele Elmo


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107629/#review24548
-----------------------------------------------------------


On Dec. 19, 2012, 4:19 p.m., David Edmundson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107629/
> -----------------------------------------------------------
> 
> (Updated Dec. 19, 2012, 4:19 p.m.)
> 
> 
> Review request for Telepathy.
> 
> 
> Description
> -------
> 
> - Add a new list model of Contacts
> - Add a ContactFactory and Contact class allowing the subclassing of Tp::Contact
> - Move capabilities hack outside of models so it can be used by future KTp::Contact
> 
> 
> Diffs
> -----
> 
>   KTp/CMakeLists.txt 64a12b22b5125d1ba44a3e82af20c8d3d7dccd73 
>   KTp/Models/CMakeLists.txt 404eee32735489a80c6e93e5f90b1db549536386 
>   KTp/Models/accounts-filter-model.cpp dd911ac294dd8aeaa7e2e1d6f8bc11665121d1ec 
>   KTp/Models/capabilities-hack-private.h aa3478faadceb55450cc9e6725c407095f8e3f94 
>   KTp/Models/capabilities-hack-private.cpp 46ba34e38bc4f4743beb032bf01992be952aaeef 
>   KTp/Models/contacts-list-model.h PRE-CREATION 
>   KTp/Models/contacts-list-model.cpp PRE-CREATION 
>   KTp/capabilities-hack-private.h PRE-CREATION 
>   KTp/capabilities-hack-private.cpp PRE-CREATION 
>   KTp/contact-factory.h PRE-CREATION 
>   KTp/contact-factory.cpp PRE-CREATION 
>   KTp/contact.h PRE-CREATION 
>   KTp/contact.cpp PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/107629/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-telepathy/attachments/20130103/9495ca13/attachment.html>