trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: April 2012

Re: [trinity-devel] Application NOT respecting 'System Administration -> Paths' setting in kcontrol

From: Darrell Anderson <humanreadable@...>
Date: Sat, 21 Apr 2012 19:34:08 -0700 (PDT)
> If I'm understanding this correctly, updated() should be
> called on every field change in kcontrol, but for whatever reason this may
> be broken for My Documents, and Tim is hoping that causing a *different*
> field to fire the event will cause kcontrol to catch the change to My
> Documents as well.
> The second field needn't be relevant to the setting you're
> actually trying to change—it just needs to make the updated() call—so
> choose one at random.

Oh, ok. I follow. Just toggle any setting, for example. :)

That does not do anything helpful either.

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. :(

Darrell