> 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