Ian, The example code you've given does already use prefixes. I'll explain below.
On Sat, Feb 28, 2015 at 7:56 PM, Ian Wadham <iandw...@gmail.com> wrote: > Hi Jeremy, > > On 28/02/2015, at 11:20 PM, Jeremy Whiting wrote: > > On Sat, Feb 28, 2015 at 4:51 AM, René J.V. <rjvber...@gmail.com> wrote: > > On Saturday February 28 2015 22:00:07 Ian Wadham wrote: > > > > We could change GenericDataDir in QStandardPaths to be: > > > > > > > > "~/Library/Application Support/Qt5", "/Library/Application > Support/Qt5" > > > > > > > > That would work for ALL applications that use Qt5 and QSP, > regardless of origin, > > > > and would be a more "correct" usage of Apple OS X by the Qt 5 > libraries. > > > Then data will all be under ~/Library/Application Support/Qt5/appname ? > that's a bit cleaner, > > Errrmm, not "all", unless there has been a change in KDE Community > designs/policy… > > App data would be INSTALLED under /Library/Application Support/Qt5/appname > (no ~) > and would be read-only. The "~" version is used by apps when they > *execute*, either > for the user of the app to override one of the read-only files (e.g. > <appname>ui.rc) or to > save personal data for that app (e.g. statistics in the KPat game). > 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. > > > but why would Qt/KDE applications need to use a namespace like that when > apple's own applications don't? > > Ahem! Why do American web addresses not have a country code? It is a > matter of > "first in, best dressed", as we say in Australia. > > Anyway, as René says, it really is best to keep Open Source files quite > separate from > Apple files, to avoid any possibility of cross-contamination, name > duplication or even > actual deletion or overwriting. That is why MacPorts uses /opt/local for > utilities and > libraries, rather than /usr/local. > > > 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. > 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. > > What I see is source-code of apps that have been ported to KF5, such as, > in Granatier [1]. > > 49 m_soundExplode = new KgSound(QStandardPaths::locate > (QStandardPaths::DataLocation, > "sounds/explode.wav")); > 102 const QStringList dirs = QStandardPaths::locateAll > > (QStandardPaths::GenericDataLocation, "granatier/arenas", > QStandardPaths::LocateDirectory); > > This has been ported and tested on Linux and Linux CI (at least) and there > it is (AFAIK) > using plain, unaltered QStandardPaths. So there should be no kf5/ > subfolder there, > unless it comes from $XDG_DATA_DIRS. > 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. > > The first lines of code will find the explosion sound, either in > /usr/local/share/granatier, > where it has been installed, OR in ~/.local/share/granatier, if the user > has their own > explosion sound. The *order* of paths in QSP ensures that the latter is > picked up first, > if it exists. It will not be found in /usr/share, because it has not been > installed there. > > The second bit of code finds all folders that contain Granatier "arenas" > (board layouts > containing bombs, etc.). These could be installed or provided by the user > (or GHNS?). > > Note that the code could have said '(QStandardPaths::DataLocation, > "arenas", '. So no > way for a "kf5" suffix to get in there. Maybe it comes from > $XDG_DATA_DIRS (?). > 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. > > Also, there would be several shared data folders in GenericDataLocation, > alongside > the DataLocation folders for the apps. See [2] for details. These would > fit in quite well > with standard paths on Apple OS X set to: > > "~/Library/Application Support/<subdir>", "/Library/Application > Support/<subdir>" > > always supposing we really *want* to be good Apple citizens. They would > not look at > all good if they were directly under "Application Support/", because they > are not apps. > 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, Jeremy > > Cheers, Ian W. > > [1] > https://projects.kde.org/projects/kde/kdegames/granatier/repository/revisions/master/entry/src/game.cpp > [2] http://api.kde.org/ecm/kde-module/KDEInstallDirs.html > >
