In the current ContactsModel we have several workarounds and extensions to Tp::Contact, whilst this works in the contact list, we end up with a situation where the contact list shows you can send file but the text-ui does not. This can be resolved with lots of duplicate code, that's not a good solution.
Whilst building a new contact list model I came up with an alternative design, subclassing Tp::Contact. Thanks to an awesome TpQt design, by creating a subclassed Tp::ContactFactory we can ensure that all Contacts created in that application are in fact KTp::Contact objects which extend Tp::Contact and can add any new methods. This means we can: - expose the gabble bug workarounds/clientTypes workaround to all components without copying/pasting code - override the presence() method to return KTp::Presences directly removing the need for casting in our code (though now they have to cast contact instead) - have methods "canSendFile()" which check selfContacts() capability built into the contact shared by the contact list models, and applications like the text-ui/contact-applet. - probably more :) This opens up to a whole new set of possibilities, we can subclass Account and have setPassword/removePassword methods and such. I think this seems a much more object oriented approach, as currently we are at risk of having several namespaces with "doSomethingWithContact(Tp::ContactPtr);" which we call throughout our code. Our current code reflects this and I think it's only going to get worse. With this new contact factory it would always be safe to convert any Tp::ContactPtr to a KTp::ContactPtr, and SharedPtr has a handy qObjectCast static method for doing so. We can pass KTp::ContactPtr's about in our code (and GlobalContactManager), so there would not be a lot of conversions needed. Also (to me) it seems like a better way of handling any KPeople code inside the _handlers_. We automatically get instant notification when any new contact becomes known to the application, without each client having to monitor the channel's groupMemebersChanged, and we don't have to have code doing lookups to a hash table all over the place which will be annoying to read. However, it's quite a large change in direction I think, so I want input from you guys. Downsides: - I can see this potentially turning into wrapping large amounts of the public API of TpQt. (not sure if this is a bad thing) - KTp::Contact and Tp::Contact may get really confusing, especially if someone writes "using namespace..." at any point. - None of the methods in Tp::Contact are virtual, which means if we were to override the block method to show the "are you sure" dialog first (for example), you would get a different behaviour happen depending on whether you had casted or not. - Any code which tried to use KTp::Contact with a standard Tp::ContactFactory would crash. - I'm not really sure if the Collabora people will tell me off for abusing the contact factory. Hope that makes sense. I have the relevant code at [email protected]:scratch/davidedmundson/groupingmodel, but this is just a staging area where I'm trying new things. Thoughts? David P.S sorry for this email being really really long :) _______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
