[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 7:51:21
[Download RAW message or body]

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

-- 
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]