Kopete/Roadmap: Difference between revisions

From KDE Community Wiki
*>Mlarouche
(Initial roadmap for Kopete 1.0 and beyond)
 
m (23 revisions imported)
 
(22 intermediate revisions by 15 users not shown)
Line 1: Line 1:
This roadmap is no mean to be solid in a rock. Things can move and nothing is final. It is just a tool to help us focus our priority work.


= For KDE 4.0 release (Kopete 1.0) =


== Better protocol support ==
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.


* New Messenger plugin
== Better protocol support (Status: not done) ==
 
* New Messenger plugin (with filetransfer working)
* Telepathy plugin with support for text, voice and video channel.
* Telepathy plugin with support for text, voice and video channel.


== Model/View for Contact List ==
== Model/View for Contact List (Status: Done for KDE 4.3) ==
 
== Improve usability (Status: not done) ==
 
* Improve handling of status message, allow editing of previous status message
* Polish UI being broken by Qt3->Qt4 migration
* Respect HIG more
 
== Full Identity support (Status: not done) ==
* Make accounts read/write user info from/to the identity instead of using their own myself() contacts.
* PIM integration?
See more on IDENTITY_REFACTORY in kopete svn.
 
== Make use of the Command pattern for most tasks (Status: not done) ==
 
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 (Status: done) ==
 
Kross is the new scripting engine for KDE4 that helps implement scripting support into an application. It supports multiple scripting languages like Python, Ruby and JavaScript(ECMAscript). It would be really nice to be able to write plugins as scripts.


Storage abstraction is already in libkopete in SVN.
There exist a working implementation including some samples in [http://websvn.kde.org/trunk/extragear/network/kopete-scripting/ extragear] now.


* Make the contact list model
== Strigi integration (Status: not done) ==
* Implement funky KopeteContactListItemDelegate
* Refactoring global identity support to not being a hack and integrate into the new model


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


* Improving handling of status message, allow editing of previous status message
== Akonadi integration (Status: not done) ==
* Polish UI being broken by Qt3->Qt4 migration
* Respect HIG more


== Make use of the Command pattern for most tasks ==
We could use for history and for the contact list. Then history's Strigi would index the Akonadi backend.


We should keep that point in mind when refactoring the contact list
== Guest mode (Status: not done) ==
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
Allow people other than the current user to use another IM account while not bloating the user settings, like a sandbox mode.
encapsulate tasks into proper object. One task, one object. Easier to
maintain too.


== Strigi integration ==


The first Strigi use case in Kopete would be history search.
== Restore IRC Plugin (Status: in progress) ==


= For KDE 4.1 release (Kopete 1.1) =
* Finish the KDE 4 port of the IRC plugin and reenable it


== Full integration of Telepathy/Decibel ==
== Full integration of Telepathy/Decibel (Status: not done) ==


* 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 going to move to full
The general consensus of everyone was that Kopete will to move to full Telepathy support in the 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
make use of Decibel (which currently Telepathy plugin doesn't use).
 
= For KDE 4.2 release (Kopete 1.2) =
 
== Guest mode ==


Allow different people than the current user to use another IM accounts while not bloating the user settings, like a sandbox mode.
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).

Latest revision as of 18:22, 18 March 2016


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.

Better protocol support (Status: not done)

  • New Messenger plugin (with filetransfer working)
  • Telepathy plugin with support for text, voice and video channel.

Model/View for Contact List (Status: Done for KDE 4.3)

Improve usability (Status: not done)

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

Full Identity support (Status: not done)

  • Make accounts read/write user info from/to the identity instead of using their own myself() contacts.
  • PIM integration?

See more on IDENTITY_REFACTORY in kopete svn.

Make use of the Command pattern for most tasks (Status: not done)

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 (Status: done)

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

There exist a working implementation including some samples in extragear now.

Strigi integration (Status: not done)

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

Akonadi integration (Status: not done)

We could use for history and for the contact list. Then history's Strigi would index the Akonadi backend.

Guest mode (Status: not done)

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


Restore IRC Plugin (Status: in progress)

  • Finish the KDE 4 port of the IRC plugin and reenable it

Full integration of Telepathy/Decibel (Status: not done)

  • 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 that Kopete will to move to full Telepathy support in the 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).