Config widgets

[Bernd Gehrmann]

On Friday 05 April 2002 12:13, you wrote:
> hello bernd,
>
> > Here are versions of the persistant class store and code completion
> > config widgets with layout management and accelerators.
> >
> > Why is the persistant class store stuff in autoproject? It is not
> > related to any kind of project management.
>
> when i was working on that i had a short discussion with you about adding
> this config stuff to gideon's project options. you suggested i should add
> it to autoproject and so i did it ( i read it as: "it is project related"
> ). 

Oops, really? :-) That must have been a misunderstanding then.
In general, I would say that configuration widgets should be where the
respective functionality is implemented, except if from the perspective
of the user interface it is more logical to put them elsewhere. Alternatively,
if things are general enough they should in the src dir. I'm not sure about
the persistant class store, but it seems that one may implement this 
differently for different languages - e.g. for Python it would probably be
a good idea to add a button "Parse all files from sys.path". So your 
configuration widget should probably be placed in cppsupport.
>
> btw: if gideon will be used for further development some docs should be
> written for people like me :) telling what the parts do and so on. it would
> help a lot if you're not working just within your part.

If you run 'doxygen Doxyfile' (after reading the HACKING file), you will get 
an overview. The interesting classes are lib/interfaces/kdev*, which contain
the abstract interfaces of various components that are guaranteed to exist
at runtime. For example, KDevLanguageSupport contains things that vary
between different programming languages (Python, PHP, C). KDevProject
contains things that behave differently for different project managements.
For example, a project for a scripting language does not need a menu item
"Build", while compiled projects need it.

Bernd.