ben at meyerhome.net
Thu Jun 26 18:24:43 BST 2003
-----BEGIN PGP SIGNED MESSAGE-----
On Thursday 26 June 2003 12:31 pm, David Faure wrote:
> On Thursday 26 June 2003 18:25, Benjamin Meyer wrote:
> > > I am trying to restore the config to the original state (as far as the
> > > user is concerned).
> > I guess the real problem stems from the fact that I am unable to
> > determine where the default value comes from when [$d] is involved. They
> > could come from within the application readEntry("foo", defaultValue) or
> > from the global config.
> [$d] really means deleted - i.e. as if the entry was not there at all, in
> the merged view (global+local).
> So obviously you get "defaultValue" from the readEntry call when you're
> reading an entry that has [$d] in the local config file.
> I believe this is what you want, right?
I want to be able to undo any changes to the local configure. I want to be
able to delete the "deleted key" so that I can get to the original global
default value. If any value (other then the value that happens to be the
same as the default value) be it setting it or deleting it is written to a
key that also has a global key then the application is unable to obtain the
Or to explain it with ktoolbar: The place where the default text position is
stated is in (for example in konsole's) global config. How do I access that
after something has been written to the local config?
I don't really get the point of [$d]. The global config's are similar to a
defined default value above and beyond what is in the binary. Only the local
configs actually change according to the user preferences. Deleting a key
should delete the local users settings and not the global configs setting
sense the only time the global config can ever come into play anyway is when
there is no settings in the local config. Added a [$d] gives the power back
in the hands of the binary to specify a default value again when the global
config has higher precedence.
Is this correct (ignoring immunity stuff which would simply take away power
from local and give to global)?
Highest priority: Local <- user can change, admin can
Middle priority: Global <- user can't change, admin can
Lowest priority: Binary <- user can't change, admin can't
When a binary running by a users calls to delete a key (which exists in both
global and local) and then calls (for example) readBoolConfig("foo", true)
kconfig shouldn't return true just because the key was deleted sense the
global defaults have higher priority over the binary defaults. deleteKey
should only delete the local config key.
When would there be a case where you would want to have [$d]? Is the global
config suppost to be anything more then a higher precedence default value
(and immunity stuff)?
- -Benjamin Meyer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
More information about the kde-core-devel