tip?

[Jens Dagerbo]

Some minor points:

On 4/19/06, Andras Mantia <amantia at kde.org> wrote:
> the ClassView, which is useless outside of C++.

Technically incorrect. The ClassView works against the code model,
which is language neutral. The ClassView works (should work) fine for,
for example, PHP.

> > 3. You could communicate with the ClassView directly, via the
> > Extension API (see kdevplugin.h) but this is only really "allowed"
> > for plugins that implement a known interface. ClassView doesn't, and
> > creating one for this single purpose seems overkill.
>
> 4. Create an interface for communication, check if the other plugin is
> loaded and communicate with the other one if possible.
[...]
> BTW, this is the same what Alexander said later in the thread.

Just to avoid confusion: 3, 4 and Alexanders' suggestion are the same
thing - Extensions.

Extensions are the right choice when you want to extend the core
application API through optionally loaded plugins that provide a
'service'. The most commonly used today is the KDevAppFrontend (grep
for it, you should find a halfdozen uses).

Adding more signals to Core is really only sensible if the broadcast
is of interest to more than one party. I'm not sure this is the case
here, but maybe it is?

If "I need a more elegant way for those two modules to communicate"
means that you need bi-directional communication between the two
plugins, I don't think we today have any suitable solution (except
maybe through signals via Core).

// jens