On Nov 11, 2015, at 12:21 PM, David Faure <fa...@kde.org<mailto:fa...@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, fa...@kde.org<mailto:fa...@kde.org>, http://www.davidfaure.fr Working on KDE Frameworks 5 -- Jake Petroules - jake.petrou...@theqtcompany.com<mailto:jake.petrou...@theqtcompany.com> Consulting Services Engineer - The Qt Company, Inc.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
