Difference between revisions of "Projects/Kopete/Roadmap"

Jump to: navigation, search
(Hella grammar fixes)
Line 1: Line 1:
This roadmap is not meant to be solid as a rock. Things can move and nothing is final. It is just a tool to help us focus our priority work.
+
This roadmap is not meant to be rock solid. Things can move and nothing is final. It is just a tool to help us focus our priorities.
  
 
= For KDE 4.0 release (Kopete 1.0) =
 
= For KDE 4.0 release (Kopete 1.0) =
Line 14: Line 14:
 
* Make the contact list model
 
* Make the contact list model
 
* Implement funky KopeteContactListItemDelegate
 
* Implement funky KopeteContactListItemDelegate
* Refactoring global identity support to not being a hack and integrate into the new model
+
* Refactor global identity support to not be a hack and integrate it into the new model
  
 
== Improve usability ==
 
== Improve usability ==
  
* Improving handling of status message, allow editing of previous status message
+
* Improve handling of status message, allow editing of previous status message
 
* Polish UI being broken by Qt3->Qt4 migration
 
* Polish UI being broken by Qt3->Qt4 migration
 
* Respect HIG more
 
* Respect HIG more
Line 24: Line 24:
 
== Make use of the Command pattern for most tasks ==  
 
== Make use of the Command pattern for most tasks ==  
  
We should keep that point in mind when refactoring the contact list  
+
We should keep that point in mind when refactoring the contact list handling. Some tasks could really use this pattern, like deleting a contact. Currently there is no way to be notified if the deletion of a contact went wrong. Most of the contacts tasks are implemented as methods of some classes, like Kopete::Contact::deleteContact which return.....void.
handling. Some tasks that could really use this pattern. Like
+
deleting a contact. There is 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  
+
Using the Command pattern allow us to use signals for notification and encapsulate tasks into proper objects. One task, one object. Easier to maintain too.
encapsulate tasks into proper object. One task, one object. Easier to  
+
maintain too.
+
  
 
== Kross integration ==
 
== Kross integration ==
  
Kross is the new scripting engine for KDE4 that help implement scriting support in a application. It support multiple scripting language like Python, Ruby and JavaScript(EMCAscript). It would be really nice to be able to write plugins as scripts.
+
Kross is the new scripting engine for KDE4 that helps implement scripting support into a application. It supports multiple scripting languages like Python, Ruby and JavaScript(EMCAscript). It would be really nice to be able to write plugins as scripts.
  
 
== Strigi integration ==
 
== Strigi integration ==
  
The first Strigi use case in Kopete would be history search.
+
The first Strigi use in Kopete would be the history search.
  
 
= For KDE 4.1 release (Kopete 1.1) =
 
= For KDE 4.1 release (Kopete 1.1) =
Line 48: Line 42:
 
* Make Kopete protocols available as Telepathy connection manager
 
* Make Kopete protocols available as Telepathy connection manager
 
* Separate libkopete into libkopete_protocols and libkopete_app (of course  
 
* Separate libkopete into libkopete_protocols and libkopete_app (of course  
with better name)
+
with a better name)
  
The general consensus of everyone was Kopete will to move to full  
+
The general consensus of everyone was Kopete will to move to full Telepathy support in a near future. But currently the Telepathy spec and Decibel are not mature enough for our needs. We need to prepare for that move because most people want to keep a BC during Kopete 1.0 period.
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.
+
  
 
Will is going to look into making our protocols available as  
 
Will is going to look into making our protocols available as  
 
connection manager.
 
connection manager.
  
Why we should split libkopete ? Because some code in libkopete are related to  
+
Why should we split libkopete? Because some code in libkopete is related to  
the application itself (and plugins) and others are related to protocol  
+
the application itself (and plugins) and others are related to protocol implementation. If we want to be more efficient and have a core library easier to maintain, we should split the library to have two distinct missions, manage the application, and help to implement the protocols.
implementation. If we want to be more efficient and have a core library more
+
easy to maintain, 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  
+
The plan is also to move most of code in Telepathy plugin into the core and  
make use of Decibel (which currently Telepathy plugin doesn't use).
+
make use of Decibel (which the Telepathy plugin doesn't use).
  
 
= For KDE 4.2 release (Kopete 1.2) =
 
= For KDE 4.2 release (Kopete 1.2) =
Line 71: Line 59:
 
== Guest mode ==
 
== Guest mode ==
  
Allow different people than the current user to use another IM accounts while not bloating the user settings, like a sandbox mode.
+
Allow people other than the current user to use another IM account while not bloating the user settings, like a sandbox mode.

Revision as of 00:30, 31 March 2007

This roadmap is not meant to be rock solid. Things can move and nothing is final. It is just a tool to help us focus our priorities.

Contents

For KDE 4.0 release (Kopete 1.0)

Better protocol support

  • New Messenger plugin
  • Telepathy plugin with support for text, voice and video channel.

Model/View for Contact List

Storage abstraction is already in libkopete in SVN.

  • Make the contact list model
  • Implement funky KopeteContactListItemDelegate
  • Refactor global identity support to not be a hack and integrate it into the new model

Improve usability

  • Improve handling of status message, allow editing of previous status message
  • Polish UI being broken by Qt3->Qt4 migration
  • Respect HIG more

Make use of the Command pattern for most tasks

We should keep that point in mind when refactoring the contact list handling. Some tasks could really use this pattern, like deleting a contact. Currently there is no way to be notified if the deletion of a contact went wrong. Most of the contacts tasks are implemented as methods 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 objects. One task, one object. Easier to maintain too.

Kross integration

Kross is the new scripting engine for KDE4 that helps implement scripting support into a application. It supports multiple scripting languages like Python, Ruby and JavaScript(EMCAscript). It would be really nice to be able to write plugins as scripts.

Strigi integration

The first Strigi use in Kopete would be the history search.

For KDE 4.1 release (Kopete 1.1)

Full integration of Telepathy/Decibel

  • Make Kopete protocols available as Telepathy connection manager
  • Separate libkopete into libkopete_protocols and libkopete_app (of course

with a better name)

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

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

Why should we split libkopete? Because some code in libkopete is 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 easier to maintain, we should split the library to have two distinct missions, manage the application, and help to implement the protocols.

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

For KDE 4.2 release (Kopete 1.2)

Guest mode

Allow people other than the current user to use another IM account while not bloating the user settings, like a sandbox mode.


KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal