[KDE/Mac] Multiplatform frameworks

[Ian Wadham]

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. <rjvbertin at 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