<div dir="ltr">Ian,<div><br></div><div>I read that KDEInstallDirs documentation, and it seems it's a bit outdated or at least not complete. If I change just -DKDE_INSTALL_DATADIR but nothing else here. kdesrc-build is installing data (stuff that went under $prefix/share) in "~/Library/Application Support" but nothing else so far. For example .desktop files for applications are currently in /usr/local/share/applications and kservice5 stuff is still in /usr/local/share/kservices5. Now after rereading that page it seems I changed the <span style="color:rgb(0,0,0);font-family:monospace;font-size:16.1499996185303px;line-height:26px;text-align:justify;background-color:rgb(236,240,243)">DATA_INSTALL_DIR but not the DATAROOTDIR, and since I set it to an absolute path it's installing those files correctly. I guess ultimately we would need/want to change all those paths on OS X. In my test here I've simply added -DKDE_INSTALL_DATADIR="/Users/jeremy/Library/Application Support" to the cmake options in my ~/.kdesrc-buildrc If there's somewhere where default cmake arguments are set per platform maybe that would be better to use and we can figure out the best places for all of these various paths one at a time.</span></div><div><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.1499996185303px;line-height:26px;text-align:justify;background-color:rgb(236,240,243)"><br></span></div><div><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.1499996185303px;line-height:26px;text-align:justify;background-color:rgb(236,240,243)">BR,</span></div><div><span style="color:rgb(0,0,0);font-family:monospace;font-size:16.1499996185303px;line-height:26px;text-align:justify;background-color:rgb(236,240,243)">Jeremy</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 1, 2015 at 7:30 PM, Ian Wadham <span dir="ltr"><<a href="mailto:iandw.au@gmail.com" target="_blank">iandw.au@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jeremy,<br>
<br>
My apologies for going back to basics.  Some things you said earlier made me<br>
think we are not on the same page, but I now see that we are.<br>
<span class=""><br>
On 02/03/2015, at 3:15 AM, Jeremy Whiting wrote:<br>
><br>
> The example code you've given does already use prefixes. I'll explain below.<br>
><br>
> On Sat, Feb 28, 2015 at 7:56 PM, Ian Wadham <<a href="mailto:iandw.au@gmail.com">iandw.au@gmail.com</a>> wrote:<br>
</span></snip><br>
<span class="">> > Note that the code could have said '(QStandardPaths::DataLocation, "arenas", '.  So no<br>
> > way for a "kf5" suffix to get in there.  Maybe it comes from $XDG_DATA_DIRS (?).<br>
><br>
> Correct, DataLocation (newly clarified as AppDataLocation) is where the application stores it's own files, so it's Application Support/<appname> In this case granatier (or whatever QApplication::setApplicationName is given in main.cpp.<br>
><br>
> > Also, there would be several shared data folders in GenericDataLocation, alongside<br>
> > the DataLocation folders for the apps.  See [2] for details.  These would fit in quite well<br>
> > with standard paths on Apple OS X set to:<br>
> ><br>
> >      "~/Library/Application Support/<subdir>", "/Library/Application Support/<subdir>"<br>
> ><br>
> > always supposing we really *want* to be good Apple citizens.  They would not look at<br>
> > all good if they were directly under "Application Support/", because they are not apps.<br>
><br>
> I'm not sure what you mean here, are you referring to kf5 frameworks, kdoctools uses kf5/kdoctools/ prefix beneath this to keep it's data separated from others, Other kf5 frameworks do the same. If they didn't we would have a ton of data in $prefix/share on linux which is also discouraged.<br>
<br>
</span>I am talking about regular apps, not Frameworks, but I am glad that Frameworks'<br>
doctools is inserting the "kf5/" subdir.<br>
<br>
If I were to build Granatier in KF5/Qt5, using standard QSP paths on OS X, I would<br>
expect to find "/Library/Application Support/granatier/" containing all the data specific<br>
to Granatier (arenas, etc.).  But also I expect "/Library/Application Support/kxmlgui5/",<br>
containing "granatierui.rc" (?), and ""/Library/Application Support/applications/" containing<br>
"granatier.desktop" (?).  Maybe there would be other subdirs, see [2], depending on<br>
whether Granatier shares other data with other apps or libraries or whether it uses shared<br>
resources such as "/Library/Application Support/icons" (?) (which I assume it does).<br>
<br>
If I have understood [2] correctly (BTW there seems to be a misprint under KXMLGUI5DIR),<br>
it seems to me that "kxmlgui5/", "applications/" and "icons/", *whatever* they contain, would<br>
be out-of-place [3] in "/Library/Application Support/" because they are not apps.  And even<br>
the application subdirs (granatier, etc.) run the risk of name-clashes with other software<br>
from sources other than KDE.  That is why I proposed a special subdir if we go the Apple<br>
and (unaltered) QStandardPaths 5.4 way.<br>
<span class=""><br>
Cheers, Ian W.<br>
<br>
> [1] <a href="https://projects.kde.org/projects/kde/kdegames/granatier/repository/revisions/master/entry/src/game.cpp" target="_blank">https://projects.kde.org/projects/kde/kdegames/granatier/repository/revisions/master/entry/src/game.cpp</a><br>
> [2] <a href="http://api.kde.org/ecm/kde-module/KDEInstallDirs.html" target="_blank">http://api.kde.org/ecm/kde-module/KDEInstallDirs.html</a><br>
<br>
</span>[3] "Out-of-place" ... "like feathers on a dog"… :-)<br>
<br>
</blockquote></div><br></div>