21 Apr
2012
21 Apr
'12
6:16 p.m.
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
21 Apr
21 Apr
9:01 p.m.
New subject: [trinity-devel] Application NOT respecting 'System Administration -> Paths' setting in kcontrol
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(a)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(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)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
9:09 p.m.
New subject: [trinity-devel] Application NOT respecting 'System Administration -> Paths' setting in kcontrol
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
9:39 p.m.
New subject: [trinity-devel] Application NOT respecting 'System Administration -> Paths' setting in kcontrol
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
22 Apr
22 Apr
2:34 a.m.
New subject: [trinity-devel] Application NOT respecting 'System Administration -> Paths' setting in kcontrol
On Sat, 21 Apr 2012 14:39:20 -0700 (PDT)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
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.
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. :)
2:34 a.m.
New subject: [trinity-devel] Application NOT respecting 'System Administration -> Paths' setting in kcontrol
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
6:40 p.m.
New subject: [trinity-devel] Application NOT respecting 'System Administration -> Paths' setting in kcontrol
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
7:38 p.m.
New subject: [trinity-devel] Application NOT respecting 'System Administration -> Paths' setting in kcontrol
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
4398
days inactive
4399
days old
7 comments
4 participants
participants (4)
-
Darrell Anderson -
David C. Rankin -
E. Liddell -
Timothy Pearson