I think this is time we schedule a realistic roadmap for Kopete 1.0

I have written a small list of things that I think shall be done at least for 
Kopete 1.0. This is just a proposal and I'm asking your input on this 
matter :)

Of course, this means a lot of work ahead for us and our manpower is limited 
and our current manpower has limited time

# ContactList Interview framework
   -Contact list model
   -New contact list view or item delegate
   -Storage into Akonadi
   -Refactor Global Identity support to integrate better into new contact list 
model and not being a hack like in KDE3

I think this point is know to everyone. We need to rewrite most, if not all 
code related to contact list handling, including the backend and the UI.
For all the fancy stuff we have for contact list in 0.12, it could be done as 
Item delegate (if you don't know what I am talking about, read Qt Interview 
framework documentation). 

Also, going the model way, instead of item-based way, is much more efficient 
for us, since we manage a lot of contacts and groups and managing all those 
Item instance would be crazy. A model allows us to just set a model to a view 
and the view is filled automatically.

# Avatar management class + UI

Fortunately, I have worked on that point and the basic scaffolding has been 
coded and put in place. We just need to port all remaining protocols to use 
it.

# Status message management UI (maybe class)

Currently I hate the fact that I can't edit status messages can I entered. 
Sometimes I made mistakes or I want to change details, but I need to rewrite 
the whole status message. So I think we shall have a UI to allow edit status 
easily.

# Make use of the Command/Job pattern for most contact management task and all 
other tasks.

I think we could keep that point in mind when refactoring the contact list 
handling. I have notified some tasks that could really use this pattern. Like 
deleting a contact. I have no way to be notified if the deletion of a contact 
went wrong. Most of the contacts tasks are implemented as method of some 
classes, like Kopete::Contact::deleteContact which return.....void.

Using the Command pattern allow us to use signals for notification and 
encapsulate tasks into proper object. One task, one object. Easier to 
maintain too.

# Make framework ready to Decibel/Telepathy move
   - Make Kopete protocols available as Telepathy connection manager
   - Separate libkopete into libkopete_protocols and libkopete_app (of course 
with better name)

The general consensus of everyone was Kopete will going to move to full 
Telepathy support in a near future. But currently Telepathy spec and Decibel 
are not mature enough to our needs. But we need to prepare for that move, 
because most people want to keep a BC during Kopete 1.0 period.

I know that Will is going to look into making our protocols available as 
connection manager.

Why we should split libkopete ? Because some code in libkopete are related to 
the application itself (and plugins) and others are related to protocol 
implementation. If we want to be more efficient and have a core library more 
easy to maintain, I think we should split the library which has two distinct 
missions, manage the application and help to implement the protocol.

Also the plan is to move most of code in Telepathy plugin into the core and 
make use of Decibel (which currently Telepathy plugin doesn't use).

# Guest mode

We discussed this point at Akademy and we though it would be really cool to 
have a guest mode in Kopete. Sometimes people want to just login temporary in 
a messaging service using the current user which have a lot of personal 
settings. 

One of the ideas was to redirect to a temporary KDEHOMEDIR and delete it on 
close of the application.

# Improve user interface usability, using the KDE4 HIG when possible because 
it is not complete.

Of course the UI would be much cooler with small improvements from the HIG :)

# Use Strigi for history search

Now that Strigi is required for kdelibs, I think we shall use it across Kopete 
when needed.

As for Nepomuk integration, I think we should wait for KDE 4.1, we have 
already a lot of work for us.

Old wiki page about Kopete Development:

http://wiki.kde.org/tiki-index.php?page=Kopete+Development
-- 
Michaël Larouche
KDE developer working on Kopete, Gamefu(KDE), Solid...on dial-up :P
--------------------------------------
Website: http://www.tehbisnatch.org/
MSN: [EMAIL PROTECTED]
IRC: irc.freenode.org/DarkShock
Jabber/email: [EMAIL PROTECTED]
_______________________________________________
kopete-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kopete-devel

Reply via email to