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).
> 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.
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.
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 (?).
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.
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
