<div dir="ltr">Ian, Others,<div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 20, 2014 at 11:47 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">Hello David,<br>
<div><div class="h5"><br>
On 20/12/2014, at 10:39 PM, David Faure wrote:<br>
> On Monday 15 December 2014 09:32:48 Ian Wadham wrote:<br>
>> A further problem is that, being a Unix-like system, OS X has many Unix-like<br>
>> and even FOSS-like items in /usr and /usr/local, such as low-level<br>
>> libraries, utilities and include files.  Many of these have the same names<br>
>> as equivalent FOSS items, but with older versions in many cases or even<br>
>> with mods by Apple.<br>
>><br>
>> For this reason, MacPorts segregates all the FOSS software it builds and<br>
>> installs into /opt/local/...  There are some words about that here:<br>
>>    <a href="https://trac.macports.org/wiki/FAQ#defaultprefix" target="_blank">https://trac.macports.org/wiki/FAQ#defaultprefix</a><br>
>><br>
>> So, if we did have some other environment variable names, e.g. QT_* not<br>
>> XDG_*, they should probably be something like MP_*.  However, environment<br>
>> variables are a threatened species on many versions of OS X supported by<br>
>> MacPorts and are extinct (i.e. ignored) on the most recent<br>
>> versions.  "Extinct" means there is no Apple-approved way to introduce an<br>
>> environment variable into an app started by the GUI facilities on the<br>
>> desktop in recent versions of OS X.<br>
>><br>
>> OTOH it is still possible to use environment variables on the command line<br>
>> in OS X.  We would *want* to use them for running CI, downstream testing<br>
>> and downstream development of mods and bug fixes, as René Bertin and I have<br>
>> been doing for KDE 4 up till now.<br>
><br>
> OK, thanks for the overview and additional context.<br>
><br>
> The way MacPorts works sounds like it could be a way to get more stuff into<br>
> QStandardPaths, basically "adding MacPorts support" to it.<br>
><br>
> The question is, what exactly does that mean :)<br>
<br>
</div></div>Yes indeed.<br>
<span class=""><br>
> Your email then goes into "non-end-user purposes" such as CI.<br>
> But what about the end user use case? That needs to work too :-)<br>
> If we (just like MacPorts) install stuff into /opt/local how do applications<br>
> find stuff there?<br>
<br>
</span>MacPorts installs libraries, utilities and non-GUI apps into /opt/local.<br>
When you install MacPorts software itself, it edits the ~/.profile file (used<br>
in OS X where you would use .bashrc in Linux).  It just adds to $PATH<br>
and $MANPATH.  That takes care of the simple stuff… :-)<br>
<br>
OS X insists on binary executables being created with full paths to libraries<br>
embedded in the file, no relative paths.  No problem finding libraries at run<br>
time… :-)  BTW, I think this is some kind of security or anti-hacking measure<br>
within OS X.<br>
<br>
GUI applications on OS X are generally installed in the /Applications tree.<br>
<br>
To avoid name clashes (I think), MacPorts installs its FOSS apps in<br>
/Applications/MacPorts. For example, there is a MacPorts version of the<br>
Gimp and another version that you can download from the Gimp website.<br>
<br>
A GUI app on OS X is a directory structure (e.g. called Firefox.app/).  It must<br>
follow a prescribed structure and contain a few mandatory files: executables<br>
(obviously), application icons in a range of sizes and an Info.plist file.  The<br>
latter is something like an <appname>.desktop file in its contents.  A classic<br>
Apple app, such as iTunes, can contain all the installed files it will ever need<br>
within the <appname.app> structure.<br>
<br>
End-users can start a GUI app by finding its icon in the /Applications area and<br>
double-clicking on it.  Or, if they use the app a lot, they can drag a copy of the<br>
icon to a taskbar known as "the Dock".  Then they can start it by clicking once.<br>
>From a command-line window, a developer-type person can start an app by<br>
using the Apple OS X "open" command.<br>
<br>
AFAIK, the <appname>.desktop files of KDE 4 are not used to start an app.<br>
<span class=""><br>
> Doesn't this require some<br>
> export XDG_DATA_DIRS=/opt/local/share and similar?<br>
> The MacPorts wiki doesn't really explain how it all ends up working, but maybe<br>
> that's because simple libs don't have such issues.<br>
<br>
</span>Now to KDE apps on MacPorts…  I only know KDE 4 methods.  KF5 on OS X is<br>
what Marko Käning has been trying to get working for several months.  His<br>
current sticking point is how to get a KDE app to access all the files it needs<br>
at run time.  I started this thread to help him out with that, but I am almost as<br>
much in the dark as he is.  However, we are starting to make some progress...<br>
<br>
MacPorts installs KDE 4 GUI apps in /Applications/MacPorts/KDE4, where they<br>
have a bare minimum of Apple-type structure (the mandatory files mentioned<br>
above).  All the other files the app may provide are installed in /opt/local with the<br>
usual KDE 4 structure (e.g. /opt/local/share/apps/kgoldrunner/, etc.).<br>
<br>
KStandardDirs can find these because CMake passes it compile-time macros<br>
which contain the required paths.  Maybe we could do something similar in<br>
QStandardPaths on MacPorts...<br>
<br>
A KDE 4 app that works with just the files it provides, such as KGoldrunner, has<br>
almost zero problems on Apple OS X.  Indeed I have been developing and bug-<br>
fixing KDE Games apps on Apple OS X for over 3 years, with no ill effects<br>
except some log messages (issued by KMessageBox) to say that notifications<br>
are not available.  René is doing some work on using Apple OS X notification<br>
facilities from KDE apps, I believe.<br>
<br>
Trouble can begin on Apple OS X and MacPorts when a KDE 4 app uses plugins,<br>
KParts, KCookieJar, DBus, Dr Konqi and other sophisticated facilities of KDE.  Our<br>
group on KDE-Mac has been working to solve some of the problems, since about<br>
March, and KDE 4 apps generally are looking a lot less "broken" than they were a<br>
year or so ago.  But we still have a long way to go.  As to KF5, we are still taking<br>
"baby steps"...<br>
<span class=""><br>
> I mean - how does it work for other XDG software than Qt and KF5, which needs<br>
> to find stuff, like, let's say, update-mime-database (or any other XDG software<br>
> that uses mimetypes), which has to find /opt/local/share/mime ?<br>
> (rather than the default location for it, which would be /usr/share/mime)<br>
<br>
</span>René has explained this.<br>
<br>
AFAIK there is very little XDG software on MacPorts, maybe just a package called<br>
xdg-utils, some Python modules and two things called libcanberra and libxdg-basedir.<br>
What XDG software did you have in mind, David?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers, Ian W.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
<a href="mailto:kde-mac@kde.org">kde-mac@kde.org</a><br>
List Information: <a href="https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac" target="_blank">https://mail.kde.org/mailman/listinfo/kde-mac<br>
KDE/Mac</a> Information: <a href="http://community.kde.org/Mac" target="_blank">http://community.kde.org/Mac</a><br>
</div></div></blockquote></div><br></div></div>