[RFC] KDevelop configuration setup

[Matt Rogers]

On Mar 26, 2007, at 3:53 PM, Andreas Pakulat wrote:

> 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:
>

Where was this change discussed? Are you referring to the thread on  
kde-core-devel or a discussion somewhere on our use of KCMultiDialog?

> 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


The project specific configuration returned by IProject should be the  
local file. As mentioned on the wiki, there should be little to add  
to the global project configuration file after the project is  
created. If something in the global file needs to be changed, then we  
should provide separate ways to do that, IMHO.
--
Matt