building kio on Mac

Ian Wadham iandw.au at gmail.com
Tue Jun 9 03:02:46 UTC 2015


On 08/06/2015, at 5:13 PM, David Faure wrote:
> On Monday 08 June 2015 15:22:20 Ben Cooksley wrote:
>> The maintainer(s) of
>> the QStandardPaths class never reviewed our patch
> 
> That would be me, and since I don't know how things should work on OSX,

a)
https://developer.apple.com/library/mac/documentation/General/Conceptual/MOSXAppProgrammingGuide/AppRuntime/AppRuntime.html
and scroll down to "A Few Important App Directories"
b)
https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/MacOSXDirectories/MacOSXDirectories.html
c)
https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW2

> I am 
> not in a good position to decide. On top of that I come from the KDE world, so 
> I can't really force a KDE patch into Qt if it's a bit controversial.

I think Apple's design philosophy is quite different from the XDG/KDE's.  So
an attempt to map XDG directories onto "equivalent" Apple OS X dirs is bound
to strike difficulties.

Read what c) above says about iOS ("Every App is an Island").  That is the O/S for
iPhones, iPads, etc.  In an ideal Apple world, every app would be completely
self-contained, apart from access to libraries and "the system", and that is the way
OS X (on Mac computers) seems to be trending.

In OS X (but not iOS), '/Library/Application Support' is allowed for apps to
be able to share data files between *users* of apps, but the preferred place
for apps to keep data files is in the "bundle" (/Applications/.../<appname>.app/),
down in sub-directory Contents/Resources/.  In KDE 4 apps, I think only application
icons are placed there (by MacPorts), so that they can appear in the Dock (for quick
launches) or in displays of /Applications directories by the OS X file manager.

By contrast, XDG/KDE apps and libraries are sharing files between *applications*,
as well as users, often in an indirect way via libraries and background processes
(whether in KDE 4 or KF5).  Apple OS X developer documentation does not forbid
this, but I have not seen any place where it supports it and says how to achieve it.
Indeed Apple doco seems to gently discourage sharing between apps in some
places and I seem to remember some rumblings about security in that connection.

Apple OS X does not *prevent* using Application Support directories in any way
you like, but I think some kind of workaround in QSP is needed to keep KF5's
usage neat and tidy and maybe even "under the radar".  Traditionally suppliers
of third party software have created their own subdirectories in Application
Support.  So my "~/Library/Application Support" and "/Library/Application Support"
directories contain folders for Mozilla/ and Oracle/.  Apple itself would have subdirs
with the names of its apps (iPhoto/, iDVD/, etc.) and some suppliers of major products
would do that too (Gimp/, audacity/).

The more recent naming convention encouraged by Apple requires the supplier's
reverse domain name as a prefix, i.e. the name should include the app's name and
its source.  So I also have org.videolan.vlc/.  I do not know whether something like
kde.org/ would be OK, with subdirs like kde.org/share and kde.org/<appname>
(I hope that is correct: I am relying on memory), but it would avoid crowding the
Application Support directories with KF5 apps.

Another thing that keeps me awake at night (not really :-)) is an OS X daemon called
"taskgated", which intercepts and security-checks process invocations.  See:
http://stackoverflow.com/questions/18423124/please-check-gdb-is-codesigned-see-taskgated8-how-to-get-gdb-installed-w
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/taskgated.8.html

At the moment, in MacPorts, taskgated is running in "Tiger" mode (i.e. as in OS X
about 10 years ago), which bypasses such checks.  But the day may come when
Apple decides to deprecate and discontinue the bypass option, in which case
software from the KDE Community will need to be codesigned on Apple OS X.

Well, I am not an expert on Apple software, but I hope this has been helpful.  The
MacPorts group has greater experts, so perhaps one of them could help KF5 and
Qt 5 people further regarding Qt's QSP and KF5's (and KDE 4's) runtime tasks.

Cheers, Ian W.






More information about the Kde-buildsystem mailing list