KDevelop4 project file

[Andras Mantia]

> made.  Finally, I've written documentation in the actual source files.
> But,
> no, you are right, I didn't discuss it here...  Sorry.

Ok, no problem with this, I just wanted to know if there was a real
discussion that I missed.

> When a project is opened any changes to the settings will be reflected in
> the
> project file(s).  When a project is not currently opened any changes to
> the
> settings will be reflected as normal... in $USER/.kde4/config/kdeveloprc
>
> This means that we have one configuration dialog for both kdevelop and the
> project.  When a project is opened it is in project mode.  When a project
> is
> not opened it is in regular 'configure kdevelop' mode.  I will be making a
> change to the top-level menu item to reflect this.  When a project is
> opened
> it will read 'configure project' and when a project is not opened it will
> read 'configure kdevelop'.

Ok, this makes sense.


> 1.  All settings are saved to the global KConfig object.  Period.  The
> framework handles the project opening behind the scenes.  Again, when a
> project is opened the framework initializes the global KConfig object to
> point to project file(s).  When a project is not currently open the
> framework
> initializes the global KConfig object to point to regular config files.

Sounds good.

>
> 2.  You SHOULD NOT access the global KConfig object through
> KGlobal::config()
> anymore.  Instead, you should access it through three different methods:
>
> 	KDevConfig::standard() <-- This is the usual way you will access it.
> Only in
> 	very rare cases will you need to access it from the other two methods.
>
> 	KDevConfig::localProject() <-- If you are making a setting without
> KConfigXT
> 	and wish to make sure the setting is NOT saved in the global shareable
> 	project file, then you can use this.
>
> 	KDevConfig::globalProject <-- You should rarely if ever use this.  It is
> 	operationally the same as standard.  It may be removed.

I think this is what I was looking for, the KDevConfig class. I'm not near
my home PC to see the sources, but what you wrote makes sense.

> 3.  You should be using KConfigXT for your settings dialogs wherever
> possible.

We were already went on this way. ;-)

[...]
Thanks for describing how it works now and what were the reasons behind
the change.

>> As I look in the code it seems that now the project file cannot be
>> accessed at all, only via KDevFileManager, to manipulate folders/files.
>> No extra information can be stored in the project file?
>> Maybe I miss something, but this is a step back compared to KDevelop3
>> architecture.
>
> No, you can no longer access the old projectdom.  That's because we are no
> longer using it.  It all goes through KConfig now.
>
> But, OF COURSE, you can access the project file.  It is just done in a
> different way... through KConfig... actually through KDevConfig ;)

Thanks again for your mail!

Andras

-- 
Quanta+ developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org