tip?

David Nolden david.nolden.kdevelop at art-master.de
Wed Apr 19 18:22:14 UTC 2006


Am Mittwoch, 19. April 2006 14:32 schrieb Andras Mantia:
> On Wednesday 19 April 2006 11:22, Jens Dagerbo wrote:
> > 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.
>
> I was sure it can be used outside of C++, but I just simplified my
> statement: Quick Open is more generic, while ClassView might be
> specific to some language parts.
>
> > Just to avoid confusion: 3, 4 and Alexanders' suggestion are the same
> > thing - Extensions.
>
> Oops, it seems I misunderstood your 3rd proposal, but yes, it's all
> about extensions.
>
> > 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).
>
> It's possible with two interfaces in the lib for each plugin. But in
> this particular case, I think one interface will be enough.
>
> Andras

Ok, now I've done it the extension-way. The problem is that the extension is 
not found. I've changed libkdevclassview.desktop so it includes 
ServiceTypes=KDevelop/Plugin,KDevelop/CodeBrowserFrontend

but when querying the extension KDevelop/CodeBrowserFrontend it is not found. 
Is there anything else to care about?

Another simpler but maybe a bit less clean solution would be similar to the 
way I did it before.. I just queried all plugins that are loaded by kdevelop, 
and dynamic-casted them until I found the right one.

David




More information about the KDevelop-devel mailing list