Moving KPrefs from libkdepim to kdelibs

Benjamin Meyer ben at meyerhome.net
Thu Jul 24 00:50:46 BST 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 23 July 2003 6:31 pm, Ingo Klöcker wrote:
> On Tuesday 22 July 2003 14:10, Benjamin Meyer wrote:
> > On Monday 21 July 2003 6:54 pm, Ingo Klöcker wrote:
> > > On Monday 21 July 2003 18:26, Benjamin Meyer wrote:
> > > > 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.
>
> I was talking about the following: We store the settings of the accounts
> in
> [Account 1]
> server=...
> ...
>
> [Account 2]
> server=...
> ...
>
> I don't see how you want to move the default values for the accounts to
> the application's global config and remove them all from the binary in
> order to achieve the same result as with KPrefs.

I want to do it to show it can be done because others say it can't be.  If 
that doesn't answer you question please restate it for is oddly worded.

> Furthermore there are certain default values, e. g. the default email
> address, which are generated dynamically.

Indeed!  And lo and behold they aren't stored in the binary right now, so what 
is your point?

> It's impossible to put this
> into a global config file but it's perfectly alright to generate these
> default values in KPrefs.

So KPrefs handles wildcards?  Like I can say group=foo* and it will understand 
that any group that starts with foo references the same data?  If that is not 
what you mean then go read my previous post again on why you _can_ put the 
default values in the global config just fine other then a little bit of an 
annoyance and extra code.

- -Benjamin Meyer

P.S.  I am in the middle of moving to a new house and so I can't spend more 
time on this thread unless someone properly shows my statements in  
http://lists.kde.org/?l=kde-core-devel&m=105880474730433&w=2 to be incorrect.

- -Benjamin Meyer

- -- 
Public Key: http://www.csh.rit.edu/~benjamin/public_key.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/Hx9W1rZ3LTw38vIRArdIAKCBW9m6+oUnzo4ouJf2SyDBCWUuEgCghdlm
LI8FPJuTrdRcRebFkWDEH8Y=
=qC9g
-----END PGP SIGNATURE-----





More information about the kde-core-devel mailing list