[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [Kopete-devel] Three more wishes. :)
From:       Martijn Klingens <klingens () kde ! org>
Date:       2002-05-29 18:50:48
[Download RAW message or body]

On Wednesday 29 May 2002 18:06, Jeff Stuart wrote:
> Hmm... is there a todo somewhere that I can look at?  And is the IRC port
> to KMM due for 0.4 or beyond?

Definitely beyond 0.4. I don't think we can do such huge API changes in one or 
two days :-)

And there is an overall todo in the kopete source dir, but I think it's a bit 
outdated, nor is there a clear roadmap for what will be done for 0.5 and what 
has to wait.

On the whole I think the API issues are most urgent. KMM is a step in the 
right direction, but it will need some changes to work well. Off the top of 
my head:
- Support for multi-person chats
- Tabs support
- More events
- Better signaling when chats are opened/closed
- Better signalling of user activity ('User blah is typing a message', 'User 
foo went offline', etc.)
- Don't store pointers to KopeteContacts, because contacts may come and go for 
one reason or another, leaving dangling pointers behind. I speak from 
personal experience with the MSN plugin... Instead, use a QString that can be 
used as unique ID (Andres, you mentioned it before, I objected, and now I 
take that back ;-). The QString should ideally be globally unique within 
Kopete to simplify contact handling. libkopete can then manage all contacts 
and do the necessary mapping to the actual contacts as used by the protocol.

Other API issues: identity support, i.e. more than one connection per 
protocol. This requires a clear inventarisation of what is truly 
protocol-specific and what is connection-specific. After that the *Protocol 
classes can be split into two. With kconf_update the existing contact info 
can be preserved in the settings (an absolute requirement or we will start 
losing users!) and the settings dialog must be adjusted to support multiple 
identities.

And another huge one: the contact list needs a serious redesign. I plan to 
address most of this one myself, because it's urgently needed for MSN. But 
with LinuxTag first it won't be before the end of June before I really have 
something to show I think.

> Yes, that's VERY VERY ugly.. :D  I'm not sure how gaim did it but... ;)  I
> also know that they want to do a complete API rewrite but they've been
> saying that for a WHILE now.. ;)

I don't believe in more or less complete API rewrites. Reasons: it makes the 
time between releases incredibly large, it makes it almost impossible to 
accept and incorporate patches to older version and it almost certainly 
introduces too much bugs in one huge burst. Examples of this:

KDE 1 -> 2
Gnome 1 -> 2
Netscape 4 -> Mozilla 1

Examples how it can also be done, by releasing often and gradually evolving 
the API:

KDE 2 -> 3
StarOffice 5 -> OpenOffice 1

And I hope Kopete will take the same road of gradually phasing older code out 
and introducing new code. Much needs a rewrite, but a rewrite at once usually 
works out bad for open source. It is what you learn at school, but not very 
practical in our case, because we have an established user base that expects 
releases, something no computer class that I know ever took into 
consideration :-)

Martijn

_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]