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

List:       kde-devel
Subject:    Re: KStandardDirs
From:       Stephan Kulow <coolo () kde ! org>
Date:       2000-08-09 13:37:47
[Download RAW message or body]

Catalin Climov wrote:
> 
> 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...
> 
I think, it's a bit nonsense to punish 99.9% of the users with a dog slow KDE
because there _might_ be someone try something that _could_ crash on _him_

Greetings, Stephan

-- 
Programmers, heed this: If someone starts asking you about
agricultural genomes, it's likely time to get a handler. 
                                zdnet.com about Torvalds
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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