> 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 > >
_______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
