kde-common/accounts in kmail's addressbook

Carsten Pfeiffer carpdjih at sp.zrz.tu-berlin.de
Thu Jun 6 10:16:46 BST 2002


On Thursday 06 June 2002 18:21, Don Sanders wrote:

> KMail could send messages to the plugin by having the plugin implement
> a dcop interface of a type known to KMail. KMail could then use the
> dcop interface of the plugin to send a message to plugin when an
> event occurs such as, say, new mail arrives.

Hm, we have QEvent, we have signals and slots and we have virtual methods, 
that a plugin could implement, why should we use DCOP for in-process 
communication? Or do you mean out-of-process plugins (then we'd have problems 
with UI integration)?

> However if possible I would prefer to avoid, delay or miminize the
> complexity of the implementation of such a  callback system. I would

It really woldn't have to be complex. Emitting some signals should suffice 
(e.g. noatun does similar things). Signals have the advantage of keeping BC, 
compared to adding virtual methods to an interface, but you don't have a 
well-defined order, in which plugins' methods are invoked.

> like to hear of some sensible examples of genuinely useful plugins
> that would require the plugins to effectively be peers of KMail.

Well, the nature of plugins is that they are usually things that people didn't 
think of before, otherwise it would get implemented directly in kmail. But 
what about a text-to-speech plugin, that reads the message to you, upon 
selection? Or a way to do something with the current message, like choosing a 
standard response when reading a typical support-mail.

> Hmm, do you think it makes sense to do plugins with dcop? If so, I
> don't expect there to be too much wailing and gnashing of teeth if
> you want to take over maintainence of the KMail dcop interface.

IMHO the dcop interface is not really suited for this job, but I'll try to 
come up with some interfaces and post them.

Carsten Pfeiffer


More information about the kde-core-devel mailing list