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

Mon Dec 22 17:37:09 UTC 2014

Ian, Others,

On Sat, Dec 20, 2014 at 11:47 PM, Ian Wadham <iandw.au at gmail.com> wrote:

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

I'm sure David meant other applications that expect files to be in certain
locations following the XDG spec, such as applications (gtk, qt, or
otherwise) that use the shared mime information in /usr/share/mime or
/opt/local/share/mime etc.

>
> Cheers, Ian W.
>
>
> _______________________________________________
> kde-mac at kde.org
> List Information: https://mail.kde.org/mailman/listinfo/kde-mac
> KDE/Mac Information: http://community.kde.org/Mac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20141222/c17a3626/attachment-0001.html>