[RFC] KDevelop configuration setup

[Andreas Pakulat]

Hi,

this is not completely thought through, but I think I should put up the
discussion now because I want to implement this on the weekend.

So Matt recently added a page to the wiki about config needs, which
means a few problems with the current way of KSettings::Dialog and
KCM's. Those are already adressed by discussing a change to
KCMultiDialog. It seems theres no objection to that change, so I'd like
to propose how KDevelop will handle configuration in the future:

App-Global Configuraton:
Using KCM's and a standard KSettings::Dialog
The KCM's should use
X-KDE-ParentApp = <real application> (i.e. kdevelop, quanta, ...)
X-KDE-ParentComponents = kdevplatform (for kcm's that should be loaded for all
kdevplatforms, else same as parentApp)
Nothing special here, action is as usual Settings->Configure KDevelop

Project Configuration:
at least 2 Ways for the invocation:
a) Submenu under Settings called Projects, with an entry for each
project containing the name
b) context menu on the projectmanagerview only
c) ???

Creation of a new Dialog class that copies some code from
KSettings::Dialog for the tree-creation (the changes to
KSettings::Dialog to support our needs are IMHO to specific for kdevelop
to go into kdelibs and it can't be easily customized). This loads kcm's
for the project and creates a KCMultiDialog from it.

The projectcontroller will have the API to show the dialog for a given
project. This means we can use KCM's for the project specific dialogs
too, which means we can leverage kdelibs code and don't need to reinvent
the weel as in kdev3.

The KCM's can be initialized with a list of strings, this will include
the path to the project configuration file(s) (the shareable and
non-shareable).

The KCM's desktop file would need to specify that its a project-specific
kcm, either by using a new property, or by leveraging the
ParentApp=kdevplatform and ParentComponent=kdevproject. Our dialog would
then only load these kcm's into a KCMultiDialog, giving them the project
config files via the arguments.

One last thing is: I think we should only load kcm's for the
projectmanagement plugin for that project and its dependecies. Also I
have the idea of loading language plugin kcm's only for languages that
the project uses, which involves keeping a list of such languages (as
querying all project files on each dialog invocation is too costly).
Other plugins kcmodules would always be loaded.

File/API wise we'd stick with the kdevplatformconfig library, but the
Config object would be removed. Accessing the app-global configuration
is (AFAIK) possibly via KGlobal::config(), the project specific
configuration will be available by asking IProject for its
configuration. I'm not sure how to approach storing something directly
into this KConfig as we need to consider non-shareable information.

Questions? Comments?

Andreas

-- 
Things will be bright in P.M.  A cop will shine a light in your face.