tip?

[Jens Dagerbo]

On Monday 17 April 2006 23:42, Matt Rogers wrote:
> On Monday 17 April 2006 18:29, David Nolden wrote:
> > You quick-search for a Class, and the whole class is showed and opened in
> > the class-view-tree. I need a more elegant way for those two modules to
> > communicate. :)
> >
> > David
> >
> > Am Montag, 17. April 2006 22:32 schrieb Jens Dagerbo:
> > > On Monday 17 April 2006 19:51, David Nolden wrote:
> > > > I have a little problem.. I need the quickopen-part to communicate
> > > > with the classview-part. Currently I do this by just getting the
> > > > plugin and letting them communicate directly, but that makes it
> > > > "unportable" as the linker says, and it doesn't seem to be a good
> > > > solution. So maybe the best way would be some signal in the core that
> > > > classview can attach to, and that quickopen can trigger, but I don't
> > > > know into which class to place them(Maybe
> > > > language-support?)
> > >
> > > That question was a bit vague.. :)  What is it that you want to
> > > achieve?
> > >
> > > // jens
>
> Is the quick search in the class view already? If not, then I would advise
> using a KListViewSearchLine (or something similar) and add it to the class
> view and have the class view open the file via the part/document
> controller. (see kdevdocumentcontroller.h in trunk, kdevpartcontroller.h in
> branch) --
> Matt
>

QuickOpen and ClassView are two different plugins, so It's hard to see a 
really clean solution to this problem:

1. The cleanest is probably what Matt seems to suggest - move the QuickOpen 
functionality into ClassView (and, presumably, FileTree(?)). This is fairly 
invasive and would force someone wanting to use QuickOpen to have ClassView 
loaded (which is a toolview, and we all seem to love to have as few as 
possible of those). Personally, I don't much use ClassView, so I wouldn't 
really like this option.

2. Implement a way for plugins to tell each other.. umm.. "Class/Method 
Opened"? This through some API in core, probably in PartController or 
ProjectManager (nothing really fits well), which would then emit a signal. 
One good thing about this is that it would probably make it possible for 
ClassView to signal itself to reopen the selected class/method when it is 
forced to reread the codemodel after a build. It really is pretty annoying 
that the ClassView closes after every build... Again, somewhat invasive. And 
ugly.

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.


Personally, I have a slight preference for "2.". Admittedly mostly because it 
could probably solve the self-closing ClassView issue. 


// jens