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

List:       kopete-devel
Subject:    Re: [Kopete-devel] more design discussions (an also,KMMF bugs)
From:       Martijn Klingens <klingens () kde ! org>
Date:       2002-05-11 23:29:30
[Download RAW message or body]

On Saturday 11 May 2002 14:27, Andres Krapf wrote:
> okay, using the KMM as the chat session is a good solution.

Since that was exactly our aim when Duncan came up with the idea of KMM I 
consider this good ;-)

> is there a way to be part of those discussions ?

Join #kopete on irc.kde.org ;-)

Seriously, one of us should have sent a small mail with a summary to 
kopete-devel. Apologies for not doing that.

> now let's take an example, icq's sendthroughserver.
> the participating actors are:
>  - the chatwindow, or more precisely the STS checkbox

Correction: the optionsWidget.

>  - the KMM which catches the signal and creates the KM
>  - the protocol which sends it
>
> when the protocol is called upon to send the message, it has to know
> whether the user wants to send it through the server or not. this
> information is held by a chatwindow element (the checkbox). and the
> protocol should not know about chatwindows, as we already stated. therefore
> the KMM has to take care of it, and pass on the information to the
> protocol.
>
> what's the catch ? well, the libkopete generic KMM can't do that, because
> we don't want to put every single option of every protocol in the generic
> KMM. that's not good design (i think you'll agree here).

But it can... it has a pointer to the optionsWidget... why not pass that in 
the KopeteMessage? I agree that it is not as clean as we may want, but at 
least it performs and scales reasonably well and it is easy and quick to 
implement. Once we have all plugins doing this we can release 0.4 and we've 
come a long end by then. *After* that we can think about the longer-term 
plans, if you ask me.

Maybe just an empty class KopeteMessagePluginData, which is contained as 
pointer in the KMM ? This way KopeteMessage itself can be kept lightweight 
and the pointer can be kept a null pointer for plugins without custom 
options. All other plugins can dynamic_cast this class to whatever they want. 
The object can be queried from optionsWidget, which is then a QWidget with 
one extra data member (the KMPluginData*) which defaults to 0L.

Either way, I seriously want to postpone any decision (and even most of the 
discussion) about this until 0.4 is out unless someone considers the lack of 
this a showstopper for 0.4.

> it doesn't. after our previous discussion, i've backed out my local changes
> on this, and i just call a KMM::messageSuccessfullySent() or something like
> that from the protocol. i wanted to commit those tonight, but may be i'll
> send them to Ian instead.

Ah, great!

> sorry, was on crack...
> AIMMessageManager* aimkmm = dynamic_cast<AIMMessageManager*> kmm;

Same here, please keep a single KMM and not a protocol-specific one.

> this is a more elegant solution to the dynamic_cast proposed up there. and
> there is a need for solving the aformentioned problem, if we want kopete
> 0.4 to support the same functionality as kopete 0.3 (see icq's
> sendthroughserver's example).

Well, you're thinking in completely the opposite direction than I... I want to 
keep as much code as possible outside the plugin and you want to subclass 
about everything in libkopete into the plugin...

> now i'm not saying my solution is the best or even good, it's just a
> solution. may be there is a simpler/better approach, i'd really like to
> hear it :-)

Hopefully this one...

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]