[KDE/Mac] [OS X] adding a link module to all KF5 targets

[Ian Wadham]

Hi Christoph, René and Samuel,

First of all, gentlemen, let's not argue and get hot under the collar.  The only
way we are going to get anywhere is by working together, helping each other
and exchanging information.

On 15/10/2015, at 9:46 AM, René J.V. Bertin wrote:
> On Wednesday October 14 2015 23:46:14 Christoph Cullmann wrote:
>> you are aware that with this we introduce just a extra platform we will get bugs
>> for? We then not have just Mac/Qt but also Mac/Qt-X11 which is not even officially
>> supported by Qt itself?

The KDE Community can provide bug support for whatever platforms it chooses.

In point of fact, its support for KDE 4 on OS X has not been at all strong in the last
5 or 6 years.  Partly this was because none of the following worked properly on
OS X --- KCrash, DrKonqi and Help->Report a bug.  I know, I spent large parts of
last year fixing them.

Marko Käning, Mario Fux and I revived this list as a place to discuss the issues.
Thanks for being subscribed, Christoph and Samuel.

What we are trying to do here is to make support for Frameworks and KF5 better,
this time around, that is if we ever get to implement them on Apple OS X and if we
have not already lost any user base that KDE products have on Apple OS X.

We are also spending some time on KDE 4 problems.

Regarding the topic at hand.  I think René has made an important breakthrough
on the QStandardPaths issue and we should be thinking about how best to take
advantage of that.

A few hours ago, Christoph wrote:
> Isn't this really all going in the completely wrong direction?
> I thought we want to have frameworks that work as native on the different
> operating systems as qt.

The KDE and Apple OS X environments have quite different design approaches
with regards to applications.  A simple mapping of XDG directories onto "native"
Apple OS X directories is not going to cut it in the long run.  Why not?

KDE and its Frameworks and KF5 successors EMBRACE file-sharing between
applications, utilities and libraries.  Any GUI app I write for KDE has to have a ui.rc
file and a .desktop file.  These have to be installed, not in an Apple OS X bundle,
but in locations where libraries and utilities written by KDE core developers can
find them, easily and _quickly_.

BTW Marko Käning and Jeremy Whiting had a "pancake landing" once, a
few months ago, when kbuildsycoca5 went looking for Desktop files in /Applications
(where the bundles go) and was taking a _huge_ time to run… :-(  I suppose it
was trawling its way through iTunes, iPhoto, iMovie, GarageBand, etc., etc.  J. had
to patch the code to avoid having it look there.

In addtion, any data files my app has must go in some "AppDataLocation" which
is a holdover from KStandardDirs, and, in QSP + KF5, that location is likely to be
/Library/Application\ Support/<appname>, although it could, more appropriately
for OS X, be /Applications/..../<appname>.app/Resources (i.e. inside the bundle,
since my app is the only one that opens those files).

Regardless of all that, in Apple OS X, applications can be installed and owned
by _users_.  I own several in my /Applications (bundle) area, such as VLC.

The stated purpose of /Library/Application\ Support, in OS X application developers'
documentation, is to hold files that are shared by _users_ of an app.  Sharing of
files, libraries, etc. between apps tends to be discouraged in such doco.  I can find
no mention of sharing between apps, although there is not much (yet) to stop you… ;-)

Looking in my own /Library/Application\ Support area there are 16 entries, all of them
subdirectories.  About half of them are app names from Apple.  The rest are names
of third-party software providers, such as Adobe and Oracle.  IOW, those providers'
files, for whatever apps they have, are tidily tucked away.

QSP makes some nodding half-hearted acknowledgement of this.  <Appname> is
described as "usually the organization name, the application name, or both, or a
unique name generated at packaging (time)".  I see no signs of this happening in
KF5.  It seems to be heading to a state where every KF5 app on OS X has a subdir
in /Library/Application\ Support under its app name alone, plus a bunch of "special"
subdirs used by KDE libraries and utilities in an XDG-like way.  That could get messy.

Nowadays, the trend in Apple software is to use reverse domain names to qualify
names and locations for software and files from a particular source (including Apple).

Back in June there was a thread on kde-core-devel called "building kio on Mac".
The archives at https://mail.kde.org/pipermail/kde-core-devel/ seem to have gone
missing, so I have attached what I wrote below.

There was not one reply, so at that point I decided to give up trying to make KDE
products better on OS X.

Christoph and Samuel, are you prepared to help us?

Cheers, Ian W.
Melbourne, Australia

------------------------------------------------------------------------------

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

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

---------------------------------------------------------------------------