[KDE/Mac] Multiplatform frameworks

Jeremy Whiting jpwhiting at kde.org
Sun Mar 1 16:15:36 GMT 2015


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

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


> 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>

More information about the kde-core-devel mailing list