I tested what David reported. My "document" path was set to $HOME. I changed the document path in KControl to $HOME/Documents. Kate/kwrite correctly used that new location.
I restored the setting in KControl to $HOME. After the change to $HOME/Documents kate/kwrite/kedit seemed stuck on insisting I use $HOME/Documents, just as David described.
I deleted the $HOME/Documents directory and then kate/kwrite honored my selection in KControl of $HOME.
When I next changed the path to something outside of $HOME, in KControl, kate/kwrite/kedit would not use that new location.
The apps seemed stuck on using either $HOME/Documents or $HOME.
Using KControl sometimes updated user-dirs.dirs. Sometimes.
Changing the path in the "My Documents" URL tab never updated $HOME/.config/user-dirs.dirs. To add to the frustration, trying to change the path in "My Documents" using the little folder icon is busted. Using that method always results in a dialog asking me to select a file. Basically a pretty good WTF? moment. :) I could change the path in "My Documents" only by typing the path.
KControl would read changes I made manually to user-dirs.dirs but typically would not change the file. "My Documents" never read or updated user-dirs.dirs.
Something is broken. In several places. Yet another example why we need serious sweat equity before releasing R14. :)
Darrell
Sorry for the top post (phone). Glad to know I wasn't crazy. Will be back home to tonight to look at this further. Thank you for testing Darrell.
David C. Rankin, J.D.,P.E.
On Apr 21, 2012, at 1:16 PM, Darrell Anderson humanreadable@yahoo.com wrote:
I tested what David reported. My "document" path was set to $HOME. I changed the document path in KControl to $HOME/Documents. Kate/kwrite correctly used that new location.
I restored the setting in KControl to $HOME. After the change to $HOME/Documents kate/kwrite/kedit seemed stuck on insisting I use $HOME/Documents, just as David described.
I deleted the $HOME/Documents directory and then kate/kwrite honored my selection in KControl of $HOME.
When I next changed the path to something outside of $HOME, in KControl, kate/kwrite/kedit would not use that new location.
The apps seemed stuck on using either $HOME/Documents or $HOME.
Using KControl sometimes updated user-dirs.dirs. Sometimes.
Changing the path in the "My Documents" URL tab never updated $HOME/.config/user-dirs.dirs. To add to the frustration, trying to change the path in "My Documents" using the little folder icon is busted. Using that method always results in a dialog asking me to select a file. Basically a pretty good WTF? moment. :) I could change the path in "My Documents" only by typing the path.
KControl would read changes I made manually to user-dirs.dirs but typically would not change the file. "My Documents" never read or updated user-dirs.dirs.
Something is broken. In several places. Yet another example why we need serious sweat equity before releasing R14. :)
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Sorry for the top post (phone). Glad to know I wasn't crazy. Will be back home to tonight to look at this further. Thank you for testing Darrell.
David C. Rankin, J.D.,P.E.
I would *guess* that changing the My Documents field never signalled updated() to kcontrol, but that changing another field did. See if it works if you consistently update another field in kcontrol when you change the My Documents setting.
Tim
I would *guess* that changing the My Documents field never signalled updated() to kcontrol, but that changing another field did. See if it works if you consistently update another field in kcontrol when you change the My Documents setting.
I'm sorry. I am not following your suggestion. :( Which fields? Where? There are only three fields in KControl:Paths and only one affects the documents location. Please explain in dunce terms. :)
I tried several ways of trying to get one or the other to recognize any change. I never saw a change when made in the MY Documents device icons URL field. (Not to mention I had to type and and could not use the little folder button.) Changing the location from KControl was sporadic. I haven't yet figured out the pattern for when KControl updated user-dirs.dir.
Changing either seemed to have no effect on any app. Everything seemed limited to $HOME or $HOME/Documents. Changing either to a location outside of $HOME had no effect.
Every time I changed either I searched $HOME for recent file changes. Nothing. $HOME is hard-coded as the default location (kstandarddirs.cpp?). I suspect that whatever controls/intercepts kdialog requests is not looking at user-dirs.dir or is not looking at that file all the time.
I'm rebuilding tdebase right now with the TSAK additions to the TDM help center. Later I'll test this in my KDE3 setup and see whether I can find a pattern there. OF course, there is no My Documents icon in KDE3 but I should still see a pattern using KControl. I think the testing key is to use a location other than the defaults so the non standard location is forced to get stored somewhere.
Darrell
On Sat, 21 Apr 2012 14:39:20 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
I would *guess* that changing the My Documents field never signalled updated() to kcontrol, but that changing another field did. See if it works if you consistently update another field in kcontrol when you change the My Documents setting.
I'm sorry. I am not following your suggestion. :( Which fields? Where? There are only three fields in KControl:Paths and only one affects the documents location. Please explain in dunce terms. :)
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.
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
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
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.
Bug reports 975 and 976 opened to address the issues.
Darrell
-
Darrell Anderson -
David C. Rankin -
E. Liddell -
Timothy Pearson