Planning 0.2

[David Edmundson]

Well done on getting 0.1 sorted out.

A big thank you to everyone who helped code, especially to Martin and
George K for sorting out all the last minute problems and tasks.

Moving forward, I think 0.2 should be a boring tidying and fixing release.

I'm proposing that we tidy up the code ready for a switch over to the
nepomuk + metacontacts etc., but we don't actually make the change. I
think it may be a good time to start updating the CL in parallel.
Obviously if development proves me wrong and it's clearly ready, that
would be super cool and we'll go with that.

The goal for this is to be done by mid October (2 1/2 months)
This should allow us to target a 0.3 release in time to line up with KDE 4.8.

Below is a (somewhat lengthy) list of the things I want to sort out for 0.2.
Let me know if you disagree with anything, or want to add something.
If there are no comments I'll start adding this stuff to bugzilla.

----

Fixing any crappy bugs that we either know about or come up from this release.

----

Restorating of the KJobs to
ensureTextChannel/ensureFileTransferFileChannel/ensureFooChannel

Goals:
 - Provide unified translation of TpQt4 error messages for all apps.
 - Make it easy to use KTeleapthy::Person in future.

These will use Tp::ContactPtr for now, when the nepomuk shizzle is
ready we simply add more constructors that use KTelepathy::Person or
KTelepathy::Contact, but they'll end up calling the Tp::ContactPtr
version of the code anyway, so it's all completely re-usable and not
wasted.

- is KJob really the right tool? It's a bit overkill, it makes the API
look very complex to someone using it where a developer using it will
see have methods to track progress etc., does it bring overhead? We
could just subclass Tp::PendingOperation (which is modelled off KJob
anyway) or build something custom. It's quite easy to write a KJob
like API.

This will be used by the CL and Dolphin plugin, and the TextUi

----

Getting the repo for telepathy-chat-handler changed.
This may involve bribing a KDE sysadmin with beer, they don't have a
defined procedure for doing a rename, but apparently "it shouldn't be
too difficult".

----

Per contact custom notifications
 - Text UI supports this, it just needs a small amount of code in the CL.

----

Fix the stupid ChatTab class in the TextUI. Either use it or get rid of it.

-----

New tooltips in the contact list

Demo created, needs a few tweaks.

----

Incoing chats in the CL

I miss the feature where the contact list would show an envelope next
to the name of someone trying to talk to me.
In reality this is quite easy to do, we make the CL act as a second approver.

unsolved problem: If you close/reopen the CL, it won't show pending
incoming things.

----

Fix key handling code in text UI, it's a frickin' mess.
 - also needs a bit more documentation throughout.

----

Tidy up the mega mess that is the main class in the contact list.
 - Needs splitting into multiple classes
 - Needs better defining of what should be public/private/protected
 - consistent naming of slots
 - generally a bit of cleaning.
 - would putting common stuff into ktelepathy make this easier?

----

Make it easier to find the most common protocols in the AccountsKCM.

The problem:
 When you create an account the protocols are in no logical order.

A solution:
 I'm thinking this could take the form of offering a list of
"MSN, Facebook, Jabber, GMail, Other".
Selecting other opens the full list.

----

Sort out global presence. No idea how to do this. Suggest discussion
at Desktop Summit.

----

Merge shadeslayers sexy status message saving thing.

----

Something always running to handle the following:
 - notify when a user comes online
 - notify when a user gets added. (CL code was a temporary bodge)
 - set status to away when screensaver gets activated.
 - set presence as busy when you watch a movie (when you disable the screensave)
 - disconnect accounts on network manager disconnect (and connect again?)
 - set status to currently playing song. (needs a method to enable/disable)

Proposed design is to make a daemon with a set of plugins, one for
each of the above (plus users can then add shit. Users love plugins).
Needs discussion at desktop summit. Maybe delay until 0.3

-----

Finish KWhiteboard

-----

Get shockolateboy92 started on his chat plasmoid.
For now we'll make a QML Plugin or plasma dataengine (not sure which)
that acts a chat observer.