[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KStandardDirs
From:       Catalin Climov <xxl () thekompany ! com>
Date:       2000-08-09 13:18:34
[Download RAW message or body]

By judicious use of monkeys and typewriters, Stephan Kulow came up with:
> Catalin Climov wrote:
> > Hi,
> >
> > I found some some weird behaviour in KDE 1.92 and I'm not sure if this is
> > a bug or a feature *grin* :). It only occurs only in some special
> > circumstances, which I've somehow managed to isolate. So, here it is:
> > Say you compile KDE 1.92 and export KDEDIR=/opt/kde-1.92 before doing the
> > ./configure step. This way KDEDIR gets set to "/opt/kde-1.92" in
> > config.h. After compilation (and installing) you do:
> > cd /opt
> > ln -s kde-1.92 kde-2
> > export KDEDIR=/opt/kde-2
> > and start KDE.
> > Now, fire up KDE Control Center, and navigate to
> > Look&Feel->Themes->Style. The "Widget style and theme" list will show
> > each theme twice.
> > I've tracked the issue down to KStandardDirs::addKDEDefaults():
> >
> > // this is where "/opt/kde-2" gets added
> >     QString kdedir = getenv("KDEDIR");
> >     if (!kdedir.isEmpty())
> >         kdedirList.append(kdedir);
> >     }
> > // this is where "/opt/kde-1.92" gets added
> >     kdedirList.append(KDEDIR);
> >
> > So, according to the code above, the same directory gets added twice,
> > with 2 differrent pathnames, but with the same QDir::canonicalPath().
> > Is this the intended behaviour ? If yes, I think it should be documented,
> > so that the application writers would be aware of it, and check for
> > canonical paths whenever they use KStandardDirs.
> > If this is a bug, I can see 2 possible ways of solving it:
> > 1. Either avoid duplicate canonical paths when adding directories. Check
> > for duplicate canonical paths in KStandardDirs::addPrefix(), or better,
> > keep canonical paths in KStandardDirs::prefixes.
> > IMHO, this si not the best solution because of at least 2 reasons:
> > - it is possible that some paths cannot be resolved at this point (i.e.
> > broken symlinks).
> > - the user could change at runtime the location a symlink points to. In
> > this case, the canonical path of a prefix will change, but KStandardDirs
> > will not be aware of the change.
> > 2. The second solution is to keep the paths as they were before and
> > resolve the canonical paths each time the user queries KStandardDirs, so
> > that a list of unique canonical paths will be returned.
>
> This is a bit too slow. I don't see your reasons - broken symlinks are
> broken symlinks and the user is not supposed to change the directory KDE is
> in at runtime of KDE apps. I think, adding a check in addPrefix is the
> right thing to do
>
> Greetings, Stephan

It is slow, but way safer (is it, indeed ?). And I know the user is not 
*supposed* to change symlinks at runtime of KDE, but there is no way to 
*stop* him doing that, right ? And what happens if he does ? The above issue 
might show up again.
Of course, if you resolve the symlinks to canonical paths at KDE startup, 
changing a symlink later won't affect the running KDE...

thx,
xxL

-- 
#define EMAIL xxl@thekompany.com
#define URL http://www.thekompany.com
:wq
segmentation fault (core dumped)
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]