[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: tip?
From:       "Jens Dagerbo" <jens.dagerbo () gmail ! com>
Date:       2006-04-19 8:22:20
Message-ID: 982543070604190122j2009a017i2a7f46f0fe5ce4 () mail ! gmail ! com
[Download RAW message or body]

Some minor points:

On 4/19/06, Andras Mantia <amantia@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

_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@barney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel

[prev in list] [next in list] [prev in thread] [next in thread]