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

Petroules Jake Jake.Petroules at theqtcompany.com
Wed Nov 11 16:32:20 CET 2015

On Nov 11, 2015, at 7:13 AM, René J.V. Bertin <rjvbertin at gmail.com<mailto:rjvbertin at gmail.com>> wrote:

On Wednesday November 11 2015 15:52:33 David Faure wrote:

Cross-posting on Qt's development ML because it seems more than relevant there. To put things in context: this discussion on kde-frameworks-devel was started because an autotest from KService deleted a good chunk from my /Applications directory before I killed it (it'd have deleted the whole folder if I'd been running an SSD).

*writableLocation* returns /Applications ? How is that possible?

Yes. It cannot be otherwise as you've probably seen making the patch below, but I can understand the choice. OTOH, app bundles can be anywhere on OS X (as long as you use LaunchServices), so it'd be just as fine to set the writable location to $HOME/Applications. You might consider that for your patch.

No, there is only one location so it must remain /Applications as expected by anyone on the OS X platform.

Another thing that occurs to me: ApplicationsLocation doesn't hold the actual applications on Linux. Are QstandardPaths locations allowed to have different interpretations (and implications) like that, across platforms?

Please test this patch before I submit it to gerrit:

diff --git a/src/corelib/io/qstandardpaths_mac.mm b/src/corelib/io/qstandardpaths_mac.mm
index d6126ce..8e030ae 100644
--- a/src/corelib/io/qstandardpaths_mac.mm
+++ b/src/corelib/io/qstandardpaths_mac.mm
@@ -162,6 +162,9 @@ QString QStandardPaths::writableLocation(StandardLocation type)
            if (type == AppConfigLocation)
            return path;
+        case ApplicationsLocation:
+            path = qttestDir + QLatin1String("/Applications");
+            return path;

That looks like what I would certainly have come up with. Will test it, but as I just posted, we'll probably want to verify certain other locations as well. And you'll probably want to include my fix to the FontsLocation which omitted /Library/Fonts and considered /System/Library/Fonts to be writable ...

--- a/qtbase/src/corelib/io/qstandardpaths_mac.mm
+++ b/qtbase/src/corelib/io/qstandardpaths_mac.mm
@@ -178,6 +178,8 @@
    case GenericCacheLocation:
    case CacheLocation:
    case RuntimeLocation:
+    case FontsLocation:
+        // the font location that is writable for all users is ~/Library/Fonts
        return macLocation(type, kUserDomain);
        return macLocation(type, kOnAppropriateDisk);
@@ -218,6 +220,12 @@
                dirs.append(bundlePath + resourcesPath);
+    if (type == FontsLocation) {
+        // /Library/Fonts
+        dirs.append(macLocation(type,kLocalDomain));
+        // /System/Library/Fonts
+        dirs.append(macLocation(type,kSystemDomain));
+    }
    const QString localDir = writableLocation(type);
    return dirs;

That won't apply, I refactored QSP recently in dev branch to drop the dependency on deprecated Carbon APIs. That font dirs problem should be fixed already, however.

I'll be reporting this to Qt, of course.
That seems premature, due to you having your own patch on top of QSP.

My own patch does nothing when XDG mode isn't activated (and that particular aspect works, as does the activation stuff). And of course I'd submit a patch that doesn't include any XDG modifications.

Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>

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/176874fc/attachment.html>

More information about the Development mailing list