KDevelop4 project file
Andras Mantia
amantia at kdewebdev.org
Thu Jul 20 14:45:32 UTC 2006
> 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
More information about the KDevelop-devel
mailing list