> 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