[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [KDE/Mac] Multiplatform frameworks
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2015-03-02 2:30:56
Message-ID: F87A921C-E453-4800-931D-2A41D8A7717A () gmail ! com
[Download RAW message or body]

Hi Jeremy,

My apologies for going back to basics.  Some things you said earlier made me
think we are not on the same page, but I now see that we are.

On 02/03/2015, at 3:15 AM, Jeremy Whiting wrote:
> 
> 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@gmail.com> wrote:
</snip>
> > 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.

I am talking about regular apps, not Frameworks, but I am glad that Frameworks'
doctools is inserting the "kf5/" subdir.

If I were to build Granatier in KF5/Qt5, using standard QSP paths on OS X, I would
expect to find "/Library/Application Support/granatier/" containing all the data \
specific to Granatier (arenas, etc.).  But also I expect "/Library/Application \
Support/kxmlgui5/", containing "granatierui.rc" (?), and ""/Library/Application \
Support/applications/" containing "granatier.desktop" (?).  Maybe there would be \
other subdirs, see [2], depending on whether Granatier shares other data with other \
apps or libraries or whether it uses shared resources such as "/Library/Application \
Support/icons" (?) (which I assume it does).

If I have understood [2] correctly (BTW there seems to be a misprint under \
KXMLGUI5DIR), it seems to me that "kxmlgui5/", "applications/" and "icons/", \
*whatever* they contain, would be out-of-place [3] in "/Library/Application Support/" \
because they are not apps.  And even the application subdirs (granatier, etc.) run \
the risk of name-clashes with other software from sources other than KDE.  That is \
why I proposed a special subdir if we go the Apple and (unaltered) QStandardPaths 5.4 \
way.

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

[3] "Out-of-place" ... "like feathers on a dog"… :-)


[prev in list] [next in list] [prev in thread] [next in thread]