KConfig Bug?

[Benjamin Meyer]

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

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 
global value.

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

iD8DBQE++yxb1rZ3LTw38vIRAuD2AJ9YXa5vvk5APKuAwRBWzLFovBd9qgCfX/Sd
CSy4fuxUt7fphcKWId/6w3A=
=FfL2
-----END PGP SIGNATURE-----