[RFC] KDevelop configuration setup

[Andreas Pakulat]

On 27.03.07 12:09:48, Matt Rogers wrote:
> 
> 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?

I was referring to the thread on k-c-d. It turned out that all we really
need to do is make sure the kcm's use the pluginname as ParentComponent
along with empty ParentApp if the kcm doesn't provide app-global
settings. Then we can use KSettings::Dialog providing the config files
to write to with the new api I'm going to check in as soon as my kdelibs
build is finished. (Of course I change kdevelop on the next
big-changes-day)

> > 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?
> 
> 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.

So whatever a developer does is a local non-shareable change? Hmm, might
make sense. That way the "change default for project type" thing you
mentioned in the wiki makes way more sense :)

Ok, for now I'll stick to that, however I'll leave out the "way to
configure defaults for a project or project type" for now, because I
have no idea how that would work Ui-wise.

Any comment wether we should have Configure->Projects->(Project A,
Project B,...) or just a context menu? 

Andreas

-- 
Everything that you know is wrong, but you can be straightened out.