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

List:       kopete-devel
Subject:    Re: [Kopete-devel] [Long] next release
From:       Andres Krapf <dae () chez ! com>
Date:       2002-04-29 13:49:22
[Download RAW message or body]

On Monday 29 April 2002 14:30, Duncan Mac-Vicar Prett wrote:
> Im working with DannyS in the job to port all plugins  to kmm.
> Jabber is already using it.
> We are doing some API changes, KopeteMessage will be changed to
> hold KopeteContacts * ( and multiple in the To: field)

yes !! the KopeteContact inside the KopeteMessage is something i wanted to see 
:-).
while we're changing the kopete message, here's another proposal:
right now, for the plugin to give feedback to the user about when a message is 
sent, it uses a KMM appendmessage. this is kind of counterintuitive and not 
ideal design, because it goes like this: "KMM signals a send message, plugin 
sends it and then adds the message to KMM so that it goes to the chatwindow".
how about doing something like "KMM signals a send message, plugin sends it 
and then emits a message when it's done". that way, we better decouple the 
chatwindow from the plugin... the plugin does it jobs and signals when it's 
done. and lets the KMM do the job of adding stuff to the chatwindow when it 
should.
one way of doing this is to add the signal inside the KopeteMessage. what's 
the advantage of that ? KMM already has the KopeteMessage because it just 
signaled for it's sending.

it would go like this:
KopeteMessage tmpMessage = KopeteMessage(whatever);
connect(tmpMessage, SIGNAL(doneSignal(KopeteMessage&)),
	this, slotAddSentMessage(KopeteMessage&));
emit messageSent(tmpMessage);

then the plugin would send it over the wire, and call message.done(), which 
would be implemented like this:
void done() { emit doneSignal(this) };

the KMM can then do something like:
void slotAddSentMessage(KopeteMessage& km) { chatwindow.append(km); };

what do you think of this approach ?

> This means the currently userID hack in KopeteContact will be removed, it
> is plugins resposability to remember who is the contact it is creating
> without add more limitations to Kopete API

i've seen the userID thing, i thought it was a feature. each protocol has a 
way of uniquely identifying a user. i thought userID was meant to keep that 
information, and be used by all protocols. i locally added a
"protected: void setUserId(QString)", to use it with AIM. if you don't like it 
as is, because a QString is too explicit, you could always create a hierarchy 
of classes like this:

class UniqueId {
	virtual bool isSame(const UniqueId&) const = 0;
}

class AIMUniqueId {
	QString mId; // screen name i think ?
	AIMUniqueId(const QString& id) { mId = id; };
	virtual bool isSame(const UniqueId&) const {
		// dynamic cast to AIMUniqueId and compare the aim identifier
	}
}

than have a protected UniqueId* id; inside KopeteContact (which would be 
responsible for it from a memory management perspective)

this has the advantage of being structured (as opposed to a simple QString) 
while still avoiding the bookkeeping inside each plugin. and allowing writing 
common code for contact list management.

> We'll create a branch to do the kopetemessage port and we'll try to port
> all plugins.
> (the branch is just because a timezone difference between DannyS and me,
> which can result in unfinished work, and uncompilable states)

i'm volunteering for AIM (and may be ICQ since they look very much alike). not 
that i use AIM a lot, but i use it as a testbed for playing with KMM. also, 
i'm willing to implement the other changes i'm proposing in this mail.

cheers,

-- 
Andres
_______________________________________________
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]