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

List:       kopete-devel
Subject:    Re: [Kopete-devel] [Long] next release
From:       Martijn Klingens <klingens () kde ! org>
Date:       2002-04-29 20:47:46
[Download RAW message or body]

On Monday 29 April 2002 22:25, Andres Krapf wrote:
> i'm not proposing to put anything in the KMM. i was proposing to add a
> search method to the ContactList (which could be implemented with a
> QMap...)

Hmm, I wanted to move the contact list out of Kopete into the general app 
actually, i.e. the non-public part of the API. I have yet to see a reason for 
plugins accessing the contactlist directly. I'd rather see Kopete manage the 
list and the plugins not even knowing about its existence.

The more classes you publicise, the more code is subject to binary 
compatibility issues when Kopete reaches 1.0 and that becomes an issue. Also, 
I think it's good practice to have a class only rely on knowledge of its own 
data members, parent class(es) (NOT parent object!), method parameters and if 
needed some const statics. That results in classes that can more or less be 
developed as black boxes, and maybe even more important, *read* as black 
boxes. Someone reading the code knows everything is 'in' the object and no 
external code is called outside these strict guidelines.

There are some exceptions where maintaining this rule results in even more 
pain, but I don't think the contact list is such a case. In classic C++ you 
had to publicise it, or at least add an interface to it, but with signals and 
slots in Qt even that is no longer needed.

> i believe all this is true, i'm just not really interested in refactoring
> the plugins right now. i'm more concerned with functionality (this doesn't
> mean i like bad designs... just that right now, functionality is what
> drives me). you can always refactor later...

Sure... I just hoped you would take the hint. Apparently I lost ;-)

> i'd go for that. except i can't... how do i get a list of all the contacts
> ? it's hidden inside contactlist. and don't tell me i should track them
> myself

Eeeek... the contact list is taboo country for you! If you requested a list of 
all items you couldn't even dynamic_cast them to yourself, because you would 
also be trying to cast items from foreign plugins, which breaks with certain 
compilers and dynamic loaders. Ok, with qcast you could circumvent that 
problem, but it would still be ugly. And iterating over all those contacts 
belonging to other protocols is kinda ugly anyway. Likely even slow if 
contact lists grow and the code is called often (which it is for each sent 
message).

What exactly is the problem with tracking them yourself? In my case it was 
mostly a matter of finding every 'new MSNContact' and 'delete contact' 
occurence in the MSN code and add the necessary one-line QMap update there. I 
added an extra if( map.contains( id ) ) around that, but if the code is 
correct, that is not even needed.

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]