On Nov 11, 2015, at 8:20 AM, René J.V. Bertin <rjvber...@gmail.com<mailto:rjvber...@gmail.com>> wrote:
On Wednesday November 11 2015 16:03:31 Petroules Jake wrote: I don't understand, what do you mean with "there is only one location"? I mean the API returns a single value, not a list. However, READable locations will return a list containing both $HOME/Applications and /Applications Ah. I hadn't even considered returning a list, just returning $HOME/Applications - at least when not running with elevated privileges. As to what users expect: has there been a poll or other evaluation of whether people actually have an expectation about what the writable ApplicationsLocation should be? It seems that given the nature of the location on OS X, there is more reason not to use the writable variant than there is to use it. It seems rather evident that applications ported from the Freedesktop universe shouldn't use ApplicationsLocation to install or search for .desktop files, for instance. .desktop files are not used on OS X. One could maybe even argue that the only relevant location would be ApplicationLocation (without the 's'), which would translate to the parent of the running application's app bundle (which would be /Applications for applications installed via the App Store). As I said, app bundles are supposed to be relocatable, and /Applications is just where Apple decided to put them by default. 5.7 I think. https://codereview.qt-project.org/#/c/122044/ Time enough to incorporate a patch for 5.5.1+ and 5.6 , or do you prefer to wait until someone messes up /System/Library/Fonts by accident like I did with /Applications? ;) On 10.11 you can't - SIP will block writes to /System. ;) Feel free to do whatever you like for test mode but do not change the existing writable paths. R -- 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
