Fwd: Bug#27716: see function under container file in project treeview

Richard Dale Richard_Dale at tipitina.demon.co.uk
Mon Jul 2 17:56:04 UTC 2001


On Mon, 02 Jul 2001, you wrote:
> On Mon, 2 Jul 2001, Richard Dale wrote:
> > Also, I needed to subclass KDevLanguageSupport like this (see below) to change
> > the way it uses subclassing the virtual methods addClass(), addMethod() and
> > addAttribute(), and to use signals instead - more flexible, and easier to
> > interface to other languages.
> 
> Sandy once had the idea to get rid of addClass() and addMethod() 
> completely and use the KDevCore::contextMenu() mechanism for that.
> I.e. the language support part would connect to this signal and
> in the slot test for
> 
>   if (context->hasType("class")) {
>     //cast to ClassContext
>     popup->insertItem("Add Method", ...)
>   }
> 
> Advantage: it's infinitely more flexible (e.g any plugin could add
> something to the class view's context menu) and the classview doesn't have
> to know anything about the language.
It seems this area needs more thought - the above idea sounds a good one to me.

I've tidied up the access method names in the class parser now anyway, the
instance variable names all start with an underscore, and the accessor methods
have the same name without the underscore. I hope that is standard enough...

> BTW, I have changed the classview to insert the 'Goto declaration' item
> only for certain languages. Does that make sense for Java or does it need
> more fine-grained control?
I would just make both 'goto declaration 'and 'goto definition' go to the
definition, but disabling the 'go to declaration' option for Java is
fine too. Note that in Objective-C you can goto both the definition and
declaration of a class, as well as methods (unlike C++, for instance).

> Oh, and can you test the GNUstep check now?
All working now - and looking very nice! I fixed a minor problem in the
Makefile.am with the gnustep.toc dependency - it now depends on two files
gnustepbase.toc.in and gnustepgui.toc.in.

-- Richard

-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«



More information about the KDevelop-devel mailing list