KGlobalSettings::documentPath returns empty string?

Andreas Pakulat apaku at gmx.de
Sun Aug 10 17:28:24 BST 2008


On 10.08.08 14:49:14, Thiago Macieira wrote:
> Andreas Pakulat wrote:
> >On 10.08.08 09:36:07, David Faure wrote:
> >> On Thursday 07 August 2008, Andreas Pakulat wrote:
> >> > So the question really is: Is that the correct behaviour for KDE?
> >>
> >> Definitely not. KGlobalSettings always returned the path of a
> >> directory that exists (homeDir by default, indeed).
> >
> >Ok, should I put this into KGS until Qt is fixed or should I fix Qt and
> >put a patch into qt-copy/patches?
> 
> Qt's not wrong. It returns the path that the system says it is, if it 
> exists. If it doesn't exist, it's not Qt's mandate to create it.

I wasn't saying Qt should create it, but Qt should maybe return a valid
path instead, i.e. $HOME if $HOME/Documents doesn't exist. Especially if
you read the API doc for storageLocation you'll notice that it says the
directory it returns might not exist.

The logic currently implemented in Qt for things like Desktop, Documents
or Pictures is: Check xdg's user-dirs.dirs, if it exists and contains
the key then return the directory, no matter wether it exists or not.
Else fallback to a default for X11 ($HOME/Documents for example) but
check wether it exists, if it doesn't give back an empty string.

OTOH I can't find any indication that there's a spec saying how Qt
should behave, I just find the current behaviour strange and quite
confusing.

Andreas

-- 
Your society will be sought by people of taste and refinement.




More information about the kde-core-devel mailing list