Moving KPrefs from libkdepim to kdelibs

Benjamin Meyer ben at
Tue Jul 22 13:10:46 BST 2003

Hash: SHA1

On Monday 21 July 2003 6:54 pm, Ingo Klöcker wrote:
> On Monday 21 July 2003 18:26, Benjamin Meyer wrote:
> > On Monday 21 July 2003 11:10 am, Waldo Bastian wrote:
> > > 3) It should be possible to use a KPrefs based config-backend
> > > together with KAutoConfig. I would even go as far as saying that
> > > KAutoConfig should _only_ support KPrefs, and not KConfig directly
> > > to promote the use of KPrefs, see 4.
> >
> > Please correct me if I am wrong (I haven't looked at KPref's code
> > sense March) but KPrefs main reason for being was it set _one_ place
> > for the default values.  If I were to move all of my default values
> > for an application to my applications global config and remove them
> > all from the binary I could achieve the same result.  Any time I
> > needed a entry I could just call config->readEntry("foo") without the
> > default value because I knew that the default value was in the global
> > list.
> Maybe I'm missing something but I don't think that this will work for
> objects like KMail's accounts, transports, identities, and all other
> config information which is available for multiple objects because
> obviously the application's global config file can't contain any
> default values for an uncountable number of accounts, transports,
> identities, etc..

I think you are confusing the applications global config with the kdeglobal 
config.  An applciation can not modify its global config, but it can modify 
the kdeglobal config.  Or put it this way: If you can't do it in the 
applications global config how do the kmail developers currently do it in the 
binary?  The user accounts etc are stored in their local configs, not the 
binary or global config.

- -Benjamin Meyer

- -- 
Public Key:
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


More information about the kde-core-devel mailing list