On Tuesday 13 March 2007 22:43:24 Michaël Larouche wrote:
> 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 :)
Thanks for taking the initiative on this, Michaël.
My response to this mail is a bit hurried as I have to dash out again but
please try to consider the points I make and try and see both sides of them.
> 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).
See my comments in the Decibel section
> # 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.
Cool.
> # 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.
Agreed, but not so much of a priority for me.
> # 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.
Full ack, we have had this for years with Kopete::Task but we have not used it
widely and never outside of libkopete. Instead we've still got our own
implementations of the Command pattern in each protocol. If you take a step
back from Kopete and think about this, it makes no sense. We've got enough
experience now to factor a lot of infrastructure out of the protocols and
into libkopete. Which leads to
> - Separate libkopete into libkopete_protocols and libkopete_app (of
> course with better name)
> 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.
Exactly, a libkopete_protocols and libkopete_core split will make both more
manageable.
> The general consensus of everyone was Kopete will going to move to full
> Telepathy support in a near future.
+1
> But currently Telepathy spec and Decibel are not mature enough to our
needs.
I am not sure that this is true. Telepathy, as the bit that defines how to
talk to a connection manager ('CM', ~= Kopete::Protocol) is pretty good. And
Decibel is maturing very quickly, and is malleable to our needs. With the
amount of redesign needed in libkopete and kopete, would it not make sense to
merge much of a redesigned libkopete_core into the Decibel daemon? And keep
the kopete frontend as an interface to Decibel.
The alternative is that we let Kopete use CMs as well as native protocols, but
for KDE integration this is suboptimal, then we have duplication of function
between libkopete and the Decibel daemon and apps probably use Decibel for IM
services, we end up with both running at the same time knocking each other's
accounts offline, it's ugly.
Quick sketch
[ Kopete UI ] [ Other KDE apps ]
| |
[ Decibel/libkopete daemon ] - [ Akonadi ]
| | |
[ Kopete derived CMs ] [ foreign CMs ]
> But we need to prepare for that
> move, because most people want to keep a BC during Kopete 1.0 period.
I think BC should come in with 4.1 at the soonest. BC for Kopete in KDE 3 has
not brought us much, and we have big changes to do.
> # Make framework ready to Decibel/Telepathy move
> - Make Kopete protocols available as Telepathy connection manager
> I know that Will is going to look into making our protocols available as
> connection manager.
> 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).
>
Working on that now and at the hackathon this weekend.
However, manpower and time are our greatest problems.
Will
--
Will Stephenson
IRC: Bille
_______________________________________________
kopete-devel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/kopete-devel
