tip?

[David Nolden]

I was thinking about number 2 as well.. that would also allow other plugins to 
hook to the same signal. 
But I too couldn't find a class that the signal perfectly fits into. 

What about maybe creating a new one, for example "CodeNavigationController".
Later that class could manage all information about the current code-context, 
which currently is computed seperately thoughout different modules.

I had no time within the last days to care about that, but tomorrow I'll look 
at it again. :) 

Doing it the way Matt proposed is not what I wanted because I want to hook the 
current quick-search-feature together with the class-view to make both more 
useful for code-navigation, not to add an additional quick-search.

David

Am Dienstag, 18. April 2006 20:27 schrieb 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
>
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at barney.cs.uni-potsdam.de
> http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel