kde-common/accounts in kmail's addressbook

[Don Sanders]

On Thursday 06 June 2002 09:16, Carsten Pfeiffer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> 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)?

I believe that If a (non-dcop based) plugin inteface is created, then 
people will want dcop interfaces that do the same thing as non-dcop 
plugin interfaces that are created.

For example you want a plugin interface to return the "current 
message", but then I want to be able to use dcop from my shell to get 
the current message and pipe it into a grep (or whatever) process.

For this reason if technically feasible I would prefer to skip the 
creation of a c++, in-process specific plugin interface (which is 
what I think you are suggesting) and just create dcop interfaces.

If it isn't technically possible or sensible to use dcop then, ok, I 
can accept that.

You raise the technical problem of UI integration. I'm not worried if 
this can't be solved nicely for out-of-process plugins, as long as it 
can be solved sensibly for in-process plugins then there's no 
drawback compared to using a non-dcop plugin interface.

> > 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.

For in-process plugins can I use dcop to return a QObject pointer and 
connect to signals that QObject emits? In that case using dcop 
doesn't add any significant complexity (compared to a non-dcop 
interface).

> > 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.

Nah. I for one have tried hard to not add new features, prefering 
instead to find an underlying problem that prompted the feature 
request and try to solve that problem. Having to add a feature or an 
option is a kind of failure.

What I'm saying is that I'm aware of a lot of feature requests, 
features that hopefully could be implemented via plugins. Features 
that haven't been implemented already because doing so would 
clutter/bloat/whatever KMail.

Eventually I hope people would create plugins that do things I hadn't 
thought about, but I think the best way to make that happen is to 
make sure it's easy to create plugins that do the things a do know 
about.

> 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.

Accessing the current message hopefully can be done with a dcop method 
we shouldn't need any signals here. If you want to emit a signal 
everytime a message is selected (or more probably when the current 
message in a main window changes) then ok you want a signal. But as I 
suggest above implementing signals with dcop for in-process plugins 
isn't significantly more complicated than for non-dcop plugins.

> > 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.

(I'm not sure dcop is right for the job, but) I can't see any reasons 
why dcop shouldn't be used.

Reading the dcop documentation 
http://developer.kde.org/documentation/library/dcop.html#sec2.2.3
had me worried, as it claims having dcop methods returning data is 
much more difficult than for normal c++ methods. But the 
documentation seems to be out of date as in practice it looks easy. 
Eg in kaddressbookiface.h there's an ASYNC method that doesn't return 
data, that makes sense, and a getNameByPhone that I guess must be 
SYNC and returns a QString.

But I don't claim to be even a dcop novice. If someone with dcop 
knowledge knows dcop can't be used to receive data simply then I 
would like to know as in that case DCOP wouldn't be suitable for use 
as a plugin interface.

Don.