[KDE/Mac] Multiplatform frameworks

[Jeremy Whiting]

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.au at 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. <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).
>

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150301/8451baee/attachment.htm>