Having a KTp::Contact

[David Edmundson]

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
git at git.kde.org: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 :)