From kopete-devel Sat May 11 23:29:30 2002 From: Martijn Klingens Date: Sat, 11 May 2002 23:29:30 +0000 To: kopete-devel Subject: Re: [Kopete-devel] more design discussions (an also,KMMF bugs) X-MARC-Message: https://marc.info/?l=kopete-devel&m=102115962507118 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 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