KDE/kdevplatform/language/duchain

Andreas Pakulat apaku at gmx.de
Mon Sep 15 18:23:16 UTC 2008


On 15.09.08 18:47:25, David Nolden wrote:
> Am Montag, 15. September 2008 18:31:31 schrieb Andreas Pakulat:
> > On 15.09.08 15:28:46, David Nolden wrote:
> > > SVN commit 861252 by zwabel:
> > >
> > > Add a comment to the assertion. Now we need to think how to load
> > > language-supports on demand.
> >
> > So you now need language support without even having a file opened from
> > that language? I'd have to check at the API but that shouldn't be too
> > hard.
> 
> The problem is, that KDevelop tries to load a DUContext of a type that 
> currently doesn't exist within KDevelop, because the language-support that 
> contains that type isn't loaded. The class-browser does some processing while 
> startup that can trigger this.
> 
> I think we need to do this: Store the name of the language-support in each 
> top-context, and when attempting to load a top-context, first check whether 
> the needed language-support is there, and if it isn't, load it.

Sounds fine to me, I guess its important that its the exact same plugin
that has created the types? Then using the pluginname as plugin-id is
the "safest" you can do right now. I'd prefer using the
X-KDevelop-Language because its independant of the actual name, but at
least in theory someone could write a different plugin using other
types for the same language... Your choice, let me know if you need any
help.

Andreas

-- 
You will be called upon to help a friend in trouble.




More information about the KDevelop-devel mailing list