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

List:       kopete-devel
Subject:    Re: [Kopete-devel] Contact List overhaul
From:       Martijn Klingens <klingens () kde ! org>
Date:       2002-06-02 12:12:44
[Download RAW message or body]

On Sunday 02 June 2002 11:39, Duncan Mac-Vicar Prett wrote:
> >  - contacts can be part of any number of groups, starting from 0 (ie no
> > group at all)
>
> as DannyS says, Jabber cant do this

Read my other reply.

> >  - contacts can be agregated into some "metacontacts", which will
> > represent a physical person. for example, if a friend of mine uses msn,
> > aim and icq, i'll be able to aggregate those 3 into one "metacontact".
>
> This is the first thing we should do.
> Kopete should be able to add people, and even you should be able to
> associate info with the person, ie: picture, etc

I rather combine all issues mentioned here, because that would allow me to 
develop it for MSN without breaking the other plugins yet, after that the 
rest can be ported and then the backwards compatibility API can be removed 
from libkopete. Cleaner if you ask me.

The only thing that HAS to go first is changing KopeteContact* with whatever 
form of ID we agree on. Otherwise we will get lots of nasty crashes and other 
problems very soon. MSN already has them, if we hadn't some workarounds in 
place all around the code.

> When you add a contact using a plugin, the add dialog should ask which
> Kopete meta person is this, so the plugin can associate it, I think Kopete

No, the other way round. Plugins don't know about meta contacts. They know 
about their own contact and they signal status changes. The meta contact 
happens to embody a real contact, receives the signal and takes the required 
measures. Plugins should be isolated more from libkopete, not less.

> should not store plugin data, just meta contact data, and the plugin should
> store the id of the person for every contact it have stored,

libkopete stores _ALL_ data, even the plugin data, and KopeteContact will get 
methods to let the plugin serialize and deserialize the required 
plugin-specific data. Most likely using a QDomNode, although QString is 
another option, and with the Sync API we need to sync online/offline changes 
we might better introduce a KopeteConfigValue class. Again an implementation 
detail and hence not part of THIS discussion.

> then, if a contact goes online, the plugin should tell Kopete that the
> metaperson is online in his protocol, and Kopete, in a consistent way
> should be able to present all information in whatever way the users want
> ie: 1 list entry per person, no matter how many protocols is this person
> in, grouped by person but distinguish between protocols, or just separated
> like used to.

This is 100% libkopete code, and should be done before the plugins are ported 
ONLY if it is absolutely required. The GUI side of things should IMHO come 
after the API.

> > these can be thought of as requirements.
> > since the overhaul is going to heavily change parts of libkopete, we'd
> > like to hear from protocol implementors (or people with good knowledge
> > about the protocols): do you want to add requirements ? (does your
> > protocol have feature X that needs support from libkopete's contacts and
> > contact list ?)
>
> I dont think we will have to change too much, the contact list should be
> redesigned mostly.
> I dont agree with fit kopete needs with the plugins, as already shown,
> there are plugings that dont support some features.

As I already said, that should be solved then, not avoided.

> Do quickly, think slowly, and discuss, communicate.

Not quickly... This has to be done rather carefully, and I'll leave to 
LinuxTag in three days and probably won't really start coding this until I'm 
back about a week later...

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]