KConfig Bug?

Benjamin Meyer ben at meyerhome.net
Sat Jun 28 16:30:07 BST 2003

Hash: SHA1

On Saturday 28 June 2003 9:09 am, Waldo Bastian wrote:
> On Saturday 28 June 2003 05:04, Benjamin Meyer wrote:
> > Just to summarize so we can move on to fixing this, there are four
> > options I see:
> This is about the problem you try to solve in ktoolbar, right?

Every single application that uses KAutoConfig/KAutoConfigDialog, KToolbar, 
KColorDialog, KMainWindow, etc  This problem actually effect probably 
anything and everything I have touched in CVS during the last year.  The 
reason I didn't catch this problem before was because of a fundamental flaw 
in my understanding of how KConfig works.  I assumed that 
$KDEDIR/share/config/kmyapprc was simply a storage of default values above 
and beyond the binary.  I didn't think a user could turn that off. (and still 
don't understand why that functionality is there.  Can someone please explain 
(beyond the whole merged comp sci reason) when a developer would actually 
want this?)

> The parse order of files is like this:
> $KDEDIR/share/config/kdeglobals
> $KDEHOME/share/config/kdeglobals
> $KDEDIR/share/config/kmyapprc
> $KDEHOME/share/config/kmyapprc

> What you want is the ability to undo any setting provided by either of the
> kmyapprc files (correct?)

Almost.  I simply want to undo settings in $KDEHOME/share/config/kmyapprc.  
This is the only file I would expect to ever be modifiable.  One would think 
that kconfig would add and remove from it and only it.

> This isn't possible in and of itself, because you do not have a way to undo
> the setting provided by $KDEDIR/share/config/kmyapprc only, your options
> are 1) Provide a new value in $KDEHOME/share/config/kmyapprc

This negates quite a bit of work that I have done in the last year.  I have 
been modifying classes so that they don't write out settings if they are the 
default values.  With this solution I would revert all of that code so that 
every class/application would spit out every setting it had no matter if the 
user had customized the setting.  This isn't the direction I wish to go.  I 
am quite pleased with the fact that when I happen to start some random 
application (can anyone say a kde game?) it doesn't (necessarily) blow a 
fully copy of its config into my local directory for no reason.

> 2) Mark the entry as deleted [$d] in $KDEHOME/share/config/kmyapprc
I can't do that because $KDEDIR/share/config/kmyapprc might contain default 
values when the binary does not (as with ktoolbar and Konsole).  Applications 
can't exactly specify default values for KToolBar/KMainWindow/etc in the 
binary and $KDEDIR/share/config/kmyapprc was my understanding of where they 
were to be stored.  In this case $KDEDIR/share/config/kmyapprc is the only 
copy of the default value.  (On a sidenote my apologies to Oswald Buddenhagen 
to my objections [written in March] to having configs in a file on the 
grounds that the binary should be able to start using defaults without the 
config file as this is already the case in many KDE apps such as Konsole )

> 3) Don't provide any entry in $KDEHOME/share/config/kmyapprc
Unfortunately calling KConfig::hasKey() returns true is there is a Entry in 
$KDEDIR/share/config/kmyapprc which forces me to want to delete it which 
brings me back to #2 (but see below for your other comment)

> There is no 
>way to force that it picks up the entry defined by the
> kdeglobals files.

Which is why I suggested adding one :)

> What you can do is
> B) Use two different entries (cq. two different groupnames) for kdeglobals
> and kmyapprc. That way you can delete the entry from kmyapprc and in the
> application (ktoolbar in this case) you can fall back to kdeglobals if
> kmyapprs doesn't provide an entry.

Kiosk users/developers would probably slaughter me if I did this.  They 
wouldn't be able to just copy their local settings for applications into the 
global, but would have to rename all of the groups.  But if this is my only 
option I will start going CVS through and changing all the code.

- -Benjamin Meyer

P.S. On a side note I now change my option on the KConfig XT thread to agree 
with Oswald Buddenhagen in moving all of the default values for an 
application to a installed file.
- -- 
Public Key: http://www.csh.rit.edu/~benjamin/public_key.asc
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org


More information about the kde-core-devel mailing list