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. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
