[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-mac
Subject: Re: [KDE/Mac] Multiplatform frameworks
From: Jeremy Whiting <jpwhiting () kde ! org>
Date: 2015-03-01 16:15:36
Message-ID: CADWV2K46x_6h=vqZHJpc_xTgBQUZdQTtEkkmzWd6b4HteQG7hQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@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
>
>
[Attachment #5 (text/html)]
<div dir="ltr">Ian,<div><br></div><div>The example code you've given does already \
use prefixes. I'll explain below.</div><div class="gmail_extra"><br><div \
class="gmail_quote">On Sat, Feb 28, 2015 at 7:56 PM, Ian Wadham <span \
dir="ltr"><<a href="mailto:iandw.au@gmail.com" \
target="_blank">iandw.au@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi Jeremy,<br> <span class=""><br>
On 28/02/2015, at 11:20 PM, Jeremy Whiting wrote:<br>
> On Sat, Feb 28, 2015 at 4:51 AM, René J.V. <<a \
href="mailto:rjvbertin@gmail.com">rjvbertin@gmail.com</a>> wrote:<br> > On \
Saturday February 28 2015 22:00:07 Ian Wadham wrote:<br> </span><span class="">> \
> > We could change GenericDataDir in QStandardPaths to be:<br> > > \
><br> > > > "~/Library/Application Support/Qt5", \
"/Library/Application Support/Qt5"<br> > > ><br>
> > > That would work for ALL applications that use Qt5 and QSP, regardless \
of origin,<br> > > > and would be a more "correct" usage of Apple \
OS X by the Qt 5 libraries.<br> <br>
</span><span class="">> Then data will all be under ~/Library/Application \
Support/Qt5/appname ? that's a bit cleaner,<br> <br>
</span>Errrmm, not "all", unless there has been a change in KDE Community \
designs/policy…<br> <br>
App data would be INSTALLED under /Library/Application Support/Qt5/appname (no ~)<br>
and would be read-only. The "~" version is used by apps when they \
*execute*, either<br> for the user of the app to override one of the read-only files \
(e.g. <appname>ui.rc) or to<br> save personal data for that app (e.g. \
statistics in the KPat game).<br></blockquote><div><br></div><div>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. \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <span class=""><br>
> but why would Qt/KDE applications need to use a namespace like that when \
apple's own applications don't?<br> <br>
</span>Ahem! Why do American web addresses not have a country code? It is a \
matter of<br> "first in, best dressed", as we say in Australia.<br>
<br>
Anyway, as René says, it really is best to keep Open Source files quite separate \
from<br> Apple files, to avoid any possibility of cross-contamination, name \
duplication or even<br> actual deletion or overwriting. That is why MacPorts uses \
/opt/local for utilities and<br> libraries, rather than /usr/local.<br>
<span class=""><br>
> 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.<br></span></blockquote><div><br></div><div>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. </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class=""> <br>
</span>What I see is source-code of apps that have been ported to KF5, such as, in \
Granatier [1].<br> <br>
49 m_soundExplode = new KgSound(QStandardPaths::locate<br>
\
(QStandardPaths::DataLocation, "sounds/explode.wav"));<br> 102 \
const QStringList dirs = QStandardPaths::locateAll<br>
\
(QStandardPaths::GenericDataLocation, \
"granatier/arenas",<br>
\
QStandardPaths::LocateDirectory);<br> <br>
This has been ported and tested on Linux and Linux CI (at least) and there it is \
(AFAIK)<br> using plain, unaltered QStandardPaths. So there should be no kf5/ \
subfolder there,<br> unless it comes from \
$XDG_DATA_DIRS.<br></blockquote><div><br></div><div>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. \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>
The first lines of code will find the explosion sound, either in \
/usr/local/share/granatier,<br> where it has been installed, OR in \
~/.local/share/granatier, if the user has their own<br> explosion sound. The \
*order* of paths in QSP ensures that the latter is picked up first,<br> if it exists. \
It will not be found in /usr/share, because it has not been installed there.<br> <br>
The second bit of code finds all folders that contain Granatier "arenas" \
(board layouts<br> containing bombs, etc.). These could be installed or provided by \
the user (or GHNS?).<br> <br>
Note that the code could have said '(QStandardPaths::DataLocation, \
"arenas", '. So no<br> way for a "kf5" suffix to get in \
there. Maybe it comes from $XDG_DATA_DIRS \
(?).<br></blockquote><div><br></div><div>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. </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>
Also, there would be several shared data folders in GenericDataLocation, \
alongside<br> the DataLocation folders for the apps. See [2] for details. These \
would fit in quite well<br> with standard paths on Apple OS X set to:<br>
<br>
"~/Library/Application Support/<subdir>", \
"/Library/Application Support/<subdir>"<br> <br>
always supposing we really *want* to be good Apple citizens. They would not look \
at<br> all good if they were directly under "Application Support/", because \
they are not apps.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>BR,</div><div>Jeremy </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>
Cheers, Ian W.<br>
<br>
[1] <a href="https://projects.kde.org/projects/kde/kdegames/granatier/repository/revisions/master/entry/src/game.cpp" \
target="_blank">https://projects.kde.org/projects/kde/kdegames/granatier/repository/revisions/master/entry/src/game.cpp</a><br>
[2] <a href="http://api.kde.org/ecm/kde-module/KDEInstallDirs.html" \
target="_blank">http://api.kde.org/ecm/kde-module/KDEInstallDirs.html</a><br> <br>
</blockquote></div><br></div></div>
[Attachment #6 (text/plain)]
_______________________________________________
kde-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://community.kde.org/Mac
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic