[Bug 157526] [Patch provided] Add a function KGlobalSettings::readXdgUserDir(const QString path) to retrieve xdg path

David Faure faure at kde.org
Thu Feb 21 23:00:53 CET 2008


------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=157526         




------- Additional Comments From faure kde org  2008-02-21 23:00 -------
First the implementation details:
* QFile f( (new KStandardDirs())->localxdgconfdir() + "/user-dirs.dirs" ): memory leak. Use something like self() instead of creating a new KStandardDirs instance.
* All this line-parsing looks like something that could be done with KConfig+KConfigGroup(&cfg,QString()) instead (which handles $HOME etc.)

About the API:
* This method should take an enum instead of a string, otherwise there's a too big risk for typos.
* The all-lowercase method name matches some old method names from Waldo but it's not good Qt/KDE API IMHO, I would make it something like userPath(...) or standardUserDirectory(...).

Where's the spec for this user-dirs.dirs file?

Also with this we have two notions of "the user's document directory": KGlobalSettings::documentPath() and the new KStandardDirs::localxdguserdir(KStandardDirs::Document).
A complete solution to that problem would invove:
* porting KGlobalSettings::desktopPath()/documentPath() to localxdguserdir(...) so that we don't have conflicting results from the two
* changing the kcontrol module to write to user-dirs.dirs - otherwise the user has to edit a file by hand to set those paths....
* ... and even migrating existing paths from kdeglobals to user-dirs.dirs so that users don't lose their configuration after upgrading kde

Alternatively, localxdguserdir should not provide access to the desktop and document paths for now, those can be marked as TODO for later I guess,
but we still need to provide a way to set those other paths (download, music, picture, video etc) from the GUI.

And finally: this is a patch for 3.5.8??? It will never go into 3.5.8, this is post-end-of-life especially for new API.
This has to go into kdelibs trunk (4.1).


More information about the Kdelibs-bugs mailing list