[Development] QStandardPaths::writableLocation() on OSX in test mode
Petroules Jake
Jake.Petroules at theqtcompany.com
Wed Nov 11 20:37:36 UTC 2015
On Nov 11, 2015, at 12:21 PM, David Faure <faure at kde.org<mailto:faure at kde.org>> wrote:
On Wednesday 11 November 2015 19:09:58 Petroules Jake wrote:
Feel free to do whatever you like for test mode but do not change the existing writable paths.
Jake, I would like to understand why you say that. As the QSP author and maintainer,
I am 100% sure that the value of writableLocation(x) should be under $HOME.
Spot the wrong value in this list of results:
Writable locations:
AppConfigLocation = $HOME/Library/Preferences/qtpaths
AppDataLocation = $HOME/Library/Application Support/qtpaths
AppLocalDataLocation = $HOME/Library/Application Support/qtpaths
ApplicationsLocation = /Applications
CacheLocation = $HOME/Library/Caches/qtpaths
ConfigLocation = $HOME/Library/Preferences
DataLocation = $HOME/Library/Application Support/qtpaths
DesktopLocation = $HOME/Desktop
DocumentsLocation = $HOME/Documents
DownloadLocation = $HOME/Downloads
FontsLocation = $HOME/Library/Fonts
GenericCacheLocation = $HOME/Library/Caches
GenericConfigLocation = $HOME/Library/Preferences
GenericDataLocation = $HOME/Library/Application Support
HomeLocation = $HOME
MoviesLocation = $HOME/Movies
MusicLocation = $HOME/Music
PicturesLocation = $HOME/Pictures
RuntimeLocation = $HOME/Library/Application Support
TempLocation = $TMPDIR
This is a bug, it was never intended for writableLocation to return a system-wide path.
I can imagine that there is actually no use case for users writing into an
ApplicationsLocation under $HOME on OSX (KDE code excluded).
But in that case making the value more consistent with the other ones can't possibly hurt.
Yes, I can agree with that -- it's completely useless to anyone, but consistent. Also, I was mistaken -- writableDirectory does indeed return $HOME/Applications now with my patch as everything is routed through the same mechanism (using NSUserDomainMask).
What we SHOULD have in Qt is something similar to NSSearchPathDomainMask so we could have a little more fine grained control. Maybe a user WANTS to write to locations in the local domain instead of the user domain (and in some cases, you DO -- like Applications).
--
David Faure, faure at kde.org<mailto:faure at kde.org>, http://www.davidfaure.fr
Working on KDE Frameworks 5
--
Jake Petroules - jake.petroules at theqtcompany.com<mailto:jake.petroules at theqtcompany.com>
Consulting Services Engineer - The Qt Company, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20151111/dbfb2e30/attachment-0001.html>
More information about the Kde-frameworks-devel
mailing list