By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 976 - "My Documents" device is broken
Summary: "My Documents" device is broken
Status: RESOLVED FIXED
Alias: None
Product: TDE
Classification: Unclassified
Component: tdebase (show other bugs)
Version: R14.0.0 [Trinity]
Hardware: All Linux
: P1 critical
Assignee: Timothy Pearson
URL:
Depends on:
Blocks: 989
  Show dependency tree / graph
 
Reported: 2012-04-22 14:37 CDT by Darrell
Modified: 2013-04-19 14:32 CDT (History)
3 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Darrell 2012-04-22 14:37:24 CDT 
* Changing the "documents" path through KControl or editing user-dirs.dirs is never reflected in the "My Documents" URL path.

* Changing the URL in the device icon "My Documents" URL path has no effect on user-dirs.dirs.

* There is no synchronizing with user-dirs.dirs. I believe the "My Documents" device uses the kxdglauncher tool. Perhaps kxdglauncher is not accessing or parsing user-dirs.dirs correctly.

* If $HOME/Documents does not exist the first time "My Documents" Properties is accessed, a popup appears asking the user to configure the location and defaults to $HOME/Documents. Therefore the applet is not reading user-dirs.dirs at all. The process should be: 1) read user-dirs.dirs, 2) when the "documents" path is defined then open the basic Properties dialog, 3) when the "documents" path is not defined then ask the user for a location.

* When the popup dialog appears requesting a "documents" path, there is no directory/folder widget next to the text box allowing a user to graphically select a location. The user must type the location or accept the default.

* The little directory/folder widget in the "My Documents" URL tab is broken (this widget should be in the previous popup dialog). The picker insists upon selecting a file rather than a directory/folder. Actually, the widget does work, but the user must select the OK button twice to return to the parent dialog. Otherwise the user has to manually type the location in the text box.
Comment 1 Timothy Pearson 2013-04-18 01:09:03 CDT 
On my system (using latest GIT HEAD):
* Editing user-dirs.dirs changes the URL pointed to by the "My Documents" device.

* Changing the "documents" path in KControl partially works if and only if the path is not set to the system wide default path, this appears to be a bug.  When I say "partially works", KControl adds a "[$e]" after XDG_DOCUMENTS_DIR which interferes with parsing of the user-dirs.dirs file.

I can confirm the remaining portions of this bug report.
Comment 2 Darrell 2013-04-18 14:10:17 CDT 
I just tried this. I enabled the My Documents special device icon.

I selected Properties from the popup menu. The URL path is the same as that in KControl and user-dirs.dirs.

Keeping the icon enabled on the desktop, I opened KControl and changed the documents path to /home/Files (a legitimate directory). I minimized KControl and used the My Documents popup menu. A dialog appears wanting me to change the path to $HOME/Documents. I select Cancel and then the URL tab shows nothing for the path.

I repeated the same process by modifying user-dirs.dirs. Again My Documents insists on changing the path to $HOME/Documents rather than just reading the config file.

I tried disabling the icon, changing the user-dirs.dirs by editing and using KControl and then reenabling My Documents. Same behavior. I did not restart Trinity in these quick tests.

From my perspective, seems My Documents does not perform a refresh or re-reading of user-dirs.dirs when using the Properties option in the popup menu. That the dialog appears asking me to set the path to $HOME/Documents indicates code must be seeing some kind of change in user-dirs.dirs, but is not refreshing itself of the modified contents of user-dirs.dirs.
Comment 3 Timothy Pearson 2013-04-18 15:01:21 CDT 
I have fixed the KControl path setting problem in GIT hashes a37d437 (tdelibs) and 6640770 (tdebase).  This does not resolve any of the unrelated "My Documents" device issues, though it will likely impact the test you just ran.

Note that the KControl XDG problems have been around for a very, very long time.  A Google search on user-dirs.dirs [$e] yields quite a few bug reports...
Comment 4 Timothy Pearson 2013-04-18 15:07:37 CDT 
Given the apparent extent of the issues you are seeing (and my inability to replicate some of them), I need to ask: Where is your user-dirs.dirs file actually located?  Mine is in ~/.config/user-dirs.dirs and the My Documents folder creation popup uses the value of XDG_DOCUMENTS_DIR as it should.
Comment 5 Darrell 2013-04-18 15:35:44 CDT 
Located at ~/.config/user-dirs.dirs.

I don't know whether this makes a difference, but my file has this:

XDG_DOCUMENTS_DIR[$e]=

All other keys do not have the [$e].
Comment 6 Timothy Pearson 2013-04-18 15:43:22 CDT 
(In reply to comment #5)
> Located at ~/.config/user-dirs.dirs.
> 
> I don't know whether this makes a difference, but my file has this:
> 
> XDG_DOCUMENTS_DIR[$e]=
> 
> All other keys do not have the [$e].

Yes, it makes a big difference.  After you have recompiled and reinstalled tdelibs and tdebase, remove the [$e] from that file and re-test this bug report.
Comment 7 Darrell 2013-04-18 16:17:31 CDT 
What does the [$e] mean? Once upon a time I knew....

More importantly, what app inserted that marker?

I won't be able to get back to this until I complete my big push to GIT --- I need to keep my local repo frozen until then. Otherwise I'll get confused. :)
Comment 8 Timothy Pearson 2013-04-18 19:02:59 CDT 
(In reply to comment #7)
> What does the [$e] mean? Once upon a time I knew....

That dollar sign expansion of the given path is enabled

> More importantly, what app inserted that marker?

The aforementioned KControl module; this has since been fixed in GIT in the hash given previously.

> I won't be able to get back to this until I complete my big push to GIT --- I
> need to keep my local repo frozen until then. Otherwise I'll get confused. :)

OK.

Much of the device URL handling is now fixed in GIT hash 2b31f11, leaving only the directory creation popup problem in the still to be fixed category,
Comment 9 Darrell 2013-04-18 19:21:43 CDT 
Ok. I see part of the problem described.

I haven't yet rebuilt, but I manually deleted the [$e]. At that point I could edit user-dirs.dirs and My Documents would not present the dialog trying to default to $HOME/Documents. The moment I changed the location through KControl, then My Documents presented the dialog and the [$e] was back in the file.

Rebuilding....
Comment 10 Timothy Pearson 2013-04-19 12:52:39 CDT 
Remaining problems with the new folder creation dialog have been fixed in GIT hash b8ed19a.  At this point I believe all the issues described in this report have been addressed, but I will leave this report open pending your test results.
Comment 11 Darrell 2013-04-19 14:32:52 CDT 
I walked through the original problem descriptions. No conflicts between My Documents, KControl, and manual editing of user-dirs.dirs. Everything now seems synchronized in real-time and behaves, at least to my mind's thinking. :)

Tagging resolved.

Thank you! :)