<div dir="ltr">Ian,<div><br></div><div>The example code you've given does already use prefixes. I'll explain below.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 28, 2015 at 7:56 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>
<span class=""><br>
On 28/02/2015, at 11:20 PM, Jeremy Whiting wrote:<br>
> On Sat, Feb 28, 2015 at 4:51 AM, René J.V. <<a href="mailto:rjvbertin@gmail.com">rjvbertin@gmail.com</a>> wrote:<br>
> On Saturday February 28 2015 22:00:07 Ian Wadham wrote:<br>
</span><span class="">> > > We could change GenericDataDir in QStandardPaths to be:<br>
> > ><br>
> > > "~/Library/Application Support/Qt5", "/Library/Application Support/Qt5"<br>
> > ><br>
> > > That would work for ALL applications that use Qt5 and QSP, regardless of origin,<br>
> > > and would be a more "correct" usage of Apple OS X by the Qt 5 libraries.<br>
<br>
</span><span class="">> Then data will all be under ~/Library/Application Support/Qt5/appname ? that's a bit cleaner,<br>
<br>
</span>Errrmm, not "all", unless there has been a change in KDE Community designs/policy…<br>
<br>
App data would be INSTALLED under /Library/Application Support/Qt5/appname (no ~)<br>
and would be read-only. The "~" version is used by apps when they *execute*, either<br>
for the user of the app to override one of the read-only files (e.g. <appname>ui.rc) or to<br>
save personal data for that app (e.g. statistics in the KPat game).<br></blockquote><div><br></div><div>Yes, I understand that stuff in /Library/Application Support/ is available to all users, but is read only. and ~/Library/Application Support/ is available only to the current user and is writable. It's exactly the same as /usr/share and ~/.local on linux. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> but why would Qt/KDE applications need to use a namespace like that when apple's own applications don't?<br>
<br>
</span>Ahem! Why do American web addresses not have a country code? It is a matter of<br>
"first in, best dressed", as we say in Australia.<br>
<br>
Anyway, as René says, it really is best to keep Open Source files quite separate from<br>
Apple files, to avoid any possibility of cross-contamination, name duplication or even<br>
actual deletion or overwriting. That is why MacPorts uses /opt/local for utilities and<br>
libraries, rather than /usr/local.<br>
<span class=""><br>
> Here I see ~/Library/Application Support/kf5 for all frameworks as it is, I don't think any frameworks or applications are using GenericDataLocation directly, they all use a subfolder of it, otherwise we would see application data files in /usr/share on linux which isn't recommended either.<br></span></blockquote><div><br></div><div>Yes, the kf5 prefix would only be used by frameworks when accessing their data. All the frameworks I've seen so far already do this, kdoctools puts its files in $prefix/share/kf5/kdoctools/customizations and so on. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>What I see is source-code of apps that have been ported to KF5, such as, in Granatier [1].<br>
<br>
49 m_soundExplode = new KgSound(QStandardPaths::locate<br>
(QStandardPaths::DataLocation, "sounds/explode.wav"));<br>
102 const QStringList dirs = QStandardPaths::locateAll<br>
(QStandardPaths::GenericDataLocation, "granatier/arenas",<br>
QStandardPaths::LocateDirectory);<br>
<br>
This has been ported and tested on Linux and Linux CI (at least) and there it is (AFAIK)<br>
using plain, unaltered QStandardPaths. So there should be no kf5/ subfolder there,<br>
unless it comes from $XDG_DATA_DIRS.<br></blockquote><div><br></div><div>Correct, this uses the granatier prefix rather than kf5. Which is fine. granatier is an application, not a kf5 framework. There are two different locations there, DataLocation (renamed to AppDataLocation in Qt 5.4 iirc) is /Library/Application Support/<appname> and ~/Library/Application Support/<appname> so it would be in a granatier subfolder of the Application Support folders to find it's sounds. then for arenas that locateAll is lookinf in the GenericDataLocation (which equates exactly to the Application Support folders) for a granatier/arenas subfolder. This is all fine imo. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The first lines of code will find the explosion sound, either in /usr/local/share/granatier,<br>
where it has been installed, OR in ~/.local/share/granatier, if the user has their own<br>
explosion sound. The *order* of paths in QSP ensures that the latter is picked up first,<br>
if it exists. It will not be found in /usr/share, because it has not been installed there.<br>
<br>
The second bit of code finds all folders that contain Granatier "arenas" (board layouts<br>
containing bombs, etc.). These could be installed or provided by the user (or GHNS?).<br>
<br>
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></blockquote><div><br></div><div>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. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>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.</div><div><br></div><div>BR,</div><div>Jeremy </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
</blockquote></div><br></div></div>