[KDE/Mac] Thoughts on standard directories in Qt5 - QStandardPaths

[Ian Wadham]

Hello David,

On 20/12/2014, at 10:39 PM, David Faure wrote:
> On Monday 15 December 2014 09:32:48 Ian Wadham wrote:
>> A further problem is that, being a Unix-like system, OS X has many Unix-like
>> and even FOSS-like items in /usr and /usr/local, such as low-level
>> libraries, utilities and include files.  Many of these have the same names
>> as equivalent FOSS items, but with older versions in many cases or even
>> with mods by Apple.
>> 
>> For this reason, MacPorts segregates all the FOSS software it builds and
>> installs into /opt/local/...  There are some words about that here:
>>    https://trac.macports.org/wiki/FAQ#defaultprefix
>> 
>> So, if we did have some other environment variable names, e.g. QT_* not
>> XDG_*, they should probably be something like MP_*.  However, environment
>> variables are a threatened species on many versions of OS X supported by
>> MacPorts and are extinct (i.e. ignored) on the most recent
>> versions.  "Extinct" means there is no Apple-approved way to introduce an
>> environment variable into an app started by the GUI facilities on the
>> desktop in recent versions of OS X.
>> 
>> OTOH it is still possible to use environment variables on the command line
>> in OS X.  We would *want* to use them for running CI, downstream testing
>> and downstream development of mods and bug fixes, as René Bertin and I have
>> been doing for KDE 4 up till now.
> 
> OK, thanks for the overview and additional context.
> 
> The way MacPorts works sounds like it could be a way to get more stuff into 
> QStandardPaths, basically "adding MacPorts support" to it.
> 
> The question is, what exactly does that mean :)

Yes indeed.

> Your email then goes into "non-end-user purposes" such as CI.
> But what about the end user use case? That needs to work too :-)
> If we (just like MacPorts) install stuff into /opt/local how do applications 
> find stuff there?

MacPorts installs libraries, utilities and non-GUI apps into /opt/local.
When you install MacPorts software itself, it edits the ~/.profile file (used
in OS X where you would use .bashrc in Linux).  It just adds to $PATH
and $MANPATH.  That takes care of the simple stuff… :-)

OS X insists on binary executables being created with full paths to libraries
embedded in the file, no relative paths.  No problem finding libraries at run
time… :-)  BTW, I think this is some kind of security or anti-hacking measure
within OS X.

GUI applications on OS X are generally installed in the /Applications tree.

To avoid name clashes (I think), MacPorts installs its FOSS apps in
/Applications/MacPorts. For example, there is a MacPorts version of the
Gimp and another version that you can download from the Gimp website.

A GUI app on OS X is a directory structure (e.g. called Firefox.app/).  It must
follow a prescribed structure and contain a few mandatory files: executables
(obviously), application icons in a range of sizes and an Info.plist file.  The
latter is something like an <appname>.desktop file in its contents.  A classic
Apple app, such as iTunes, can contain all the installed files it will ever need
within the <appname.app> structure.

End-users can start a GUI app by finding its icon in the /Applications area and
double-clicking on it.  Or, if they use the app a lot, they can drag a copy of the
icon to a taskbar known as "the Dock".  Then they can start it by clicking once.
From a command-line window, a developer-type person can start an app by
using the Apple OS X "open" command.

AFAIK, the <appname>.desktop files of KDE 4 are not used to start an app.

> Doesn't this require some
> export XDG_DATA_DIRS=/opt/local/share and similar?
> The MacPorts wiki doesn't really explain how it all ends up working, but maybe 
> that's because simple libs don't have such issues.

Now to KDE apps on MacPorts…  I only know KDE 4 methods.  KF5 on OS X is
what Marko Käning has been trying to get working for several months.  His
current sticking point is how to get a KDE app to access all the files it needs
at run time.  I started this thread to help him out with that, but I am almost as
much in the dark as he is.  However, we are starting to make some progress...

MacPorts installs KDE 4 GUI apps in /Applications/MacPorts/KDE4, where they
have a bare minimum of Apple-type structure (the mandatory files mentioned
above).  All the other files the app may provide are installed in /opt/local with the
usual KDE 4 structure (e.g. /opt/local/share/apps/kgoldrunner/, etc.).

KStandardDirs can find these because CMake passes it compile-time macros
which contain the required paths.  Maybe we could do something similar in
QStandardPaths on MacPorts...

A KDE 4 app that works with just the files it provides, such as KGoldrunner, has
almost zero problems on Apple OS X.  Indeed I have been developing and bug-
fixing KDE Games apps on Apple OS X for over 3 years, with no ill effects
except some log messages (issued by KMessageBox) to say that notifications
are not available.  René is doing some work on using Apple OS X notification
facilities from KDE apps, I believe.

Trouble can begin on Apple OS X and MacPorts when a KDE 4 app uses plugins,
KParts, KCookieJar, DBus, Dr Konqi and other sophisticated facilities of KDE.  Our
group on KDE-Mac has been working to solve some of the problems, since about
March, and KDE 4 apps generally are looking a lot less "broken" than they were a
year or so ago.  But we still have a long way to go.  As to KF5, we are still taking
"baby steps"...

> I mean - how does it work for other XDG software than Qt and KF5, which needs 
> to find stuff, like, let's say, update-mime-database (or any other XDG software 
> that uses mimetypes), which has to find /opt/local/share/mime ?
> (rather than the default location for it, which would be /usr/share/mime)

René has explained this.

AFAIK there is very little XDG software on MacPorts, maybe just a package called
xdg-utils, some Python modules and two things called libcanberra and libxdg-basedir.
What XDG software did you have in mind, David?

Cheers, Ian W.