[KDE/Mac] Multiplatform frameworks

[Ian Wadham]

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 <aleixpol at kde.org> wrote:
> On Thu, Feb 26, 2015 at 10:45 AM, René J.V. <rjvbertin at 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