kde-common/accounts in kmail's addressbook
sanders at trolltech.com
Wed Jun 12 17:10:59 BST 2002
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
> > 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
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
> 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
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.
More information about the kde-core-devel