<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Nov 11, 2015, at 7:13 AM, René J.V. Bertin <<a href="mailto:rjvbertin@gmail.com" class="">rjvbertin@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">On Wednesday November 11 2015 15:52:33 David Faure wrote:<br class="">
<br class="">
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).<br class="">
<br class="">
<blockquote type="cite" class="">*writableLocation* returns /Applications ? How is that possible?<br class="">
</blockquote>
<br class="">
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.<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>No, there is only one location so it must remain /Applications as expected by anyone on the OS X platform.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">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?<br class="">
<br class="">
<blockquote type="cite" class="">Please test this patch before I submit it to gerrit:<br class="">
<br class="">
<br class="">
diff --git a/src/corelib/io/qstandardpaths_mac.mm b/src/corelib/io/qstandardpaths_mac.mm<br class="">
index d6126ce..8e030ae 100644<br class="">
--- a/src/corelib/io/qstandardpaths_mac.mm<br class="">
+++ b/src/corelib/io/qstandardpaths_mac.mm<br class="">
@@ -162,6 +162,9 @@ QString QStandardPaths::writableLocation(StandardLocation type)<br class="">
if (type == AppConfigLocation)<br class="">
appendOrganizationAndApp(path);<br class="">
return path;<br class="">
+ case ApplicationsLocation:<br class="">
+ path = qttestDir + QLatin1String("/Applications");<br class="">
+ return path;<br class="">
default:<br class="">
break;<br class="">
}<br class="">
</blockquote>
<br class="">
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 ...<br class="">
<br class="">
--- a/qtbase/src/corelib/io/qstandardpaths_mac.mm<br class="">
+++ b/qtbase/src/corelib/io/qstandardpaths_mac.mm<br class="">
@@ -178,6 +178,8 @@<br class="">
case GenericCacheLocation:<br class="">
case CacheLocation:<br class="">
case RuntimeLocation:<br class="">
+ case FontsLocation:<br class="">
+ // the font location that is writable for all users is ~/Library/Fonts<br class="">
return macLocation(type, kUserDomain);<br class="">
default:<br class="">
return macLocation(type, kOnAppropriateDisk);<br class="">
@@ -218,6 +220,12 @@<br class="">
dirs.append(bundlePath + resourcesPath);<br class="">
}<br class="">
}<br class="">
+ if (type == FontsLocation) {<br class="">
+ // /Library/Fonts<br class="">
+ dirs.append(macLocation(type,kLocalDomain));<br class="">
+ // /System/Library/Fonts<br class="">
+ dirs.append(macLocation(type,kSystemDomain));<br class="">
+ }<br class="">
const QString localDir = writableLocation(type);<br class="">
dirs.prepend(localDir);<br class="">
return dirs;<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>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.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">I'll be reporting this to Qt, of course.<br class="">
</blockquote>
That seems premature, due to you having your own patch on top of QSP.<br class="">
</blockquote>
<br class="">
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.<br class="">
<br class="">
R.<br class="">
_______________________________________________<br class="">
Development mailing list<br class="">
<a href="mailto:Development@qt-project.org" class="">Development@qt-project.org</a><br class="">
http://lists.qt-project.org/mailman/listinfo/development<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
<div apple-content-edited="true" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
-- <br class="">
Jake Petroules - <a href="mailto:jake.petroules@theqtcompany.com" class="">jake.petroules@theqtcompany.com</a><br class="">
Consulting Services Engineer - The Qt Company, Inc.</div>
</div>
<br class="">
</body>
</html>