22 Apr
2012
22 Apr
'12
11:40 a.m.
I don't know the source code, but seems when
$HOME/Documents
exists then that will always be the choice in kdialog
regardless of what I set elsewhere. In this specific test,
changing KControl:Paths did update user-dirs.dir but
Kate/Kwrite/Kedit all wanted to open in $HOME/Documents.
Manually deleting $HOME/Documents then got the editors not
to look in $HOME/Documents but they all looked in $HOME.
Even when I used KControl to change to a directory outside
$HOME, they all three would not look in that new location.
All of this happens after logging out and deleting the
ksycoca cache too. The problem then seems to be coding and
not caching, even if that was possible.
I would look in the code to see whether the existence of
$HOME/Documents mistakenly overrides user-dirs.dir. The
second glitch is why the apps don't correctly look in
user-dirs.dir or don't honor that location.
I know this worked at one time. I don't remember how long
ago. :(
The pattern seems to be this:
* The contents of user-dirs.dirs is ignored in kdialog.
* If $HOME/Documents exists, then always use $HOME/Documents as the "documents"
path in kdialog.
* If $HOME/Documents does not exist, then use $HOME as the "documents" path in
kdialog.
* Changing the URL in the psuedo device icon "My Documents" has no effect on
user-dirs.dirs.
* Changing the "documents" path through KControl or editing user-dirs.dirs is
never reflected in "My Documents" icon.
Darrell