<div dir="ltr">David,<div><br></div><div>Those are all good points, I'd forgotten about the aspect of other applications using frameworks libraries. Your mail made me remember something that Thiago suggested on irc a couple of weeks ago that may help also. His idea is using the library/framework's disk location (if that can be determined at runtime) to get a relative path for other xdg-like locations. For example if an application that is using sonnet which is in /opt/local/lib/libKF5SonnetCore.5.dylib is loaded in an application QStandardPaths could add /opt/local/share to it's GenericDataLocation and such. As I type this I'm not sure how that would work technically though. I guess sonnet (and all frameworks that utilize QSP to find their data) itself would need some code that it called to add such a path to QStandardPaths somehow right? This solution could be used to get the "default" path instead of hard coding /opt/local and has the advantage that it would work when using kdesrc-build which defaults to install into /usr/local like linux and would also work for any MacPorts install path. It would also work for any Qt application that uses any frameworks, as long as the installers for those applications put the frameworks' data files relative to the frameworks themselves. We could still do the XDG_DATA_DIRS and XDG_CONFIG_DIRS parsing also for the CI system, but it may not be needed there either since test applications linking to other libraries would also get those paths relative to the libraries themselves.</div><div><br></div><div>Ok, after a minute of thought it could be implemented like this:</div><div>QStandardPaths::addRelativePaths(const QString &path); where path is the path to a library. Relative paths to this path (converted into absolute paths) would be added to QStandardPaths values at run time. Then each framework that uses QSP to find data files could in any constructor do QStandardPaths::addRelativePaths(mypath); once and be done, right?</div><div><br></div><div>More food for thought.</div><div><br></div><div>BR,</div><div>Jeremy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 4, 2015 at 4:04 AM, David Faure <span dir="ltr"><<a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Saturday 03 January 2015 15:12:36 René J.V. Bertin wrote:<br>
> On Saturday January 03 2015 12:00:50 David Faure wrote:<br>
> > It's not Qt that puts stuff into ${prefix}/share and ${prefix}/etc/xdg,<br>
> > it's the apps.<br>
><br>
> Hmm. So even if changing this kind of setting (adding paths to the front of<br>
> a lookup list) in a new bit of code prepended to the standard<br>
> Q(Core)Application initialisation routine, I'd personally still prefer to<br>
> activate that selectively. Probably through a compile-time flag, to avoid<br>
> having to change client code.<br>
<br>
</span>A compile-time flag ... for Qt, or for apps?<br>
<br>
For Qt would be a very bad idea, unless it's customary to install Qt twice on<br>
the system, once in a proper Mac OSX location and once in a MacPorts location?<br>
If that's not how people do this, and a single Qt is used, then a compile-time<br>
flag for Qt can't work.<br>
<br>
For apps ...well, I don't see how that flag would affect the behavior of<br>
QStandardPaths. Unless you add code to every app that uses a framework, but<br>
then it's about adding some code in main() (bad idea, not modular!), not a<br>
compile-time flag (-Dsomething).<br>
<span class=""><br>
> > Well, my initial suggestion was to add support for XDG_* env vars to QSP,<br>
> > we could do that *without* a default value of /opt/local (unlike my<br>
> > current patch), so that nothing happens unless these vars are set. It<br>
> > would do exactly that - not affect non-MacPorts apps. This would indeed<br>
> > be "less intrusive".<br>
><br>
> Only if you can set those variables only for the applications that require<br>
> them!<br>
<br>
</span>I have to disagree with that "fear of breaking things by adding search paths".<br>
<br>
For instance, on my system I have XDG_DATA_DIRS set globally to my own KDE<br>
install prefix (+ /usr/share of course). And yet I use apps that don't need<br>
this (firefox, skype, libreoffice, etc.). And what breaks? Nothing. They don't<br>
care for the extra lookup path, since they are looking for their own things,<br>
which are not in there anyway.<br>
<span class="im HOEnZb"><br>
--<br>
David Faure, <a href="mailto:faure@kde.org">faure@kde.org</a>, <a href="http://www.davidfaure.fr" target="_blank">http://www.davidfaure.fr</a><br>
Working on KDE Frameworks 5<br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<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></div></div></blockquote></div><br></div>