[Development] QStandardPaths::writableLocation() on OSX in test mode

Petroules Jake Jake.Petroules at theqtcompany.com
Wed Nov 11 20:09:58 CET 2015

On Nov 11, 2015, at 8:20 AM, René J.V. Bertin <rjvbertin at gmail.com<mailto:rjvbertin at 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.


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://lists.qt-project.org/pipermail/development/attachments/20151111/115a2009/attachment.html>

More information about the Development mailing list