Hi Jeremy,
On 27/02/2015, at 2:03 PM, Jeremy Whiting wrote:
> Yeah, obviously to share with all users installing data files into
> /Library/Application Support/ is better, I just didn't do that in my test
> since my user doesn't own that folder and I didn't want to install with sudo
> for a test.
>
> On Thu, Feb 26, 2015 at 7:26 PM, Aleix Pol <aleix...@kde.org> wrote:
> On Thu, Feb 26, 2015 at 10:45 AM, René J.V. <rjvber...@gmail.com> wrote:
> > On Wednesday February 25 2015 19:10:08 Jeremy Whiting wrote:
> >
> >>QStandardPaths there that worked pretty well. In discussion with the Qt
> >>developers I began to think that we maybe should be installing our data
> >>files in the places that QStandardPaths expect to find them, rather than
> >>get QStandardPaths to find files in linuxy paths.
> >
> > Even if that were the easy way out, I don't think it's the proper solution
> > if not only because OS X and MS Windows are multi-user machines and are
> > maybe more often used like that than Linux desktop installs. Installing
> > stuff in $HOME/Library/Application Support is thus not an option (besides,
> > there's that obnoxious space in the filename that's bound to cause issues).
> >
> IIRC, the solution is using /Library instead, although my OS X
> knowledge is rusty. Aleix
Where to begin? Firstly, when dealing with KDE apps (by which I mean
"applications coming from the KDE Community"), there are three storage
requirements for application data-files:
a) Writeable, specific to the app and one user only
b) Read-only, specific to the app and shareable between users (e.g. game
data)
c) Read-only and shareable among KDE apps and users (e.g. icons, mime types)
On Apple OS X, QStandardPaths offers us two GenericDataLocations:
"~/Library/Application Support", "/Library/Application Support"
and three AppDataLocations (formerly called DataLocations):
"~/Library/Application Support/<APPNAME>", "/Library/Application
Support/<APPNAME>",
"<APPDIR>/../Resources"
One problem is that these are NOT exactly like "~/.local/share",
"/usr/local/share",
"~/.local/share/<APPNAME>" and "/usr/local/share/<APPNAME>" on Linux.
On Linux, <APPNAME> is the bare, unqualified name of the app (e.g. "kmymoney"),
so
we can safely append the appname to GenericDataLocation or ask QSP for
DataLocation
and get the same result both times. Both these practices are recommended in
the porting
notes for KStandardDirs and I have seen occurrences of both in a ported app.
If we want to be good citizens on the Apple platform ("when in Rome", etc.),
here is what
Apple's documentation says about how to use "Application Support" directories
(see [1]):
"Use this directory to store all app data files except those associated
with the user’s documents."
"All content in this directory should be placed in a custom subdirectory
whose name is that of
your app’s bundle identifier or your company."
A bundle identifier is something like "org.kde.<appname>". Actually, on my
system I find:
Tara:~>ls /Library/Application\ Support/
Adobe/ Macromedia/ ProApps/ iLife/
Apple/ Microsoft/ Script Editor/ iLifeMediaBrowser/
CrashReporter/ Mozilla/ avbdeviced/ iLifeSlideshow/
GarageBand/ Oracle/ iDVD/ iPhoto/
All are either names of organisations or names of apps from Apple.
In "~/Library/Application Support", you see much of the same. There are some
occurrences
of "bundle identifier" and a few apps that use appname without the organization
prefix, but
that is naughty, except for Apple apps (iPhoto, etc.).
Another problem is that the "/Library/Application Support" directory is not
really geared towards
apps that share data-files with other apps. Subdirs of GenericDataDir such as
doc/, kservices5/,
icons/, kxmlgui5/ , mime/ and dbus-1/ would look out-of-place, since they are
not apps. Also the
sheer number of KDE apps would tend to crowd out names of other organisation
and apps.
One way to solve both problems is somehow to inject an organisation-id, such as
KDE/ or
org.kde/ into QStandardPaths, so that the generic data paths would become
something like:
"~/Library/Application Support/KDE", "/Library/Application Support/KDE"
Then the subdir could contain the same sub-structure as the "share" directory
does in Linux.
But I do not know how or when this could be done. Clearly, we cannot hard-wire
that into
the QSP code, because there are other apps that use Qt but do not come from the
KDE
Community. It would be easy enough to put it into ECM modules when building
KF5 or
Frameworks software, but then how would that info be given to QSP within
*every* KF5
executable, GUI or not-GUI, before the first call to QSP?
Ideas welcome… :-)
Cheers, Ian W.
[1]
https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1
