<div dir="ltr">David,<div><br></div><div>Your patch is missing QLatin1String() around the "/opt/local/share" c string :). In trying this I think we have a couple of options as Rene pointed out.</div><div><br></div><div>1. Support reading XDG_CONFIG_DIRS</div><div>2. Support some compiled in or runtime programatically added alternative path(s)</div><div><br></div><div>1 would certainly be much faster and would fix the CI systems and building with kdesrc-build on mac (and a similar approach could be done on windows), but has the drawback of using environment variables, which would need to also be set by applications when launching them. This seems like a big drawback imo.</div><div>2 would take a bit of thought but would be more usable (think kde applications .app bundles that could be opened directly without setting any environment variables or other tricks) The problem with this approach is that it doesn't fix the CI system issue of needing to set custom data paths for unit tests.</div><div><br></div><div>Thoughts on these ideas? My plan at the end of december was to submit and revise Marko's patch which does similar to your patch david except that it does extract XDG_DATA_DIRS (and doesn't touch XDG_CONFIG_DIRS yet).</div><div><br></div><div>BR,</div><div>Jeremy</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 3, 2015 at 7:12 AM, René J.V. <span dir="ltr"><<a href="mailto:rjvbertin@gmail.com" target="_blank">rjvbertin@gmail.com</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 January 03 2015 12:00:50 David Faure wrote:<br>
<br>
> It's not Qt that puts stuff into ${prefix}/share and ${prefix}/etc/xdg,<br>
> it's the apps.<br>
<br>
</span>Hmm. So even if changing this kind of setting (adding paths to the front of a lookup list) in a new bit of code prepended to the standard Q(Core)Application initialisation routine, I'd personally still prefer to activate that selectively. Probably through a compile-time flag, to avoid having to change client code.<br>
<span class=""><br>
> > That'd work<br>
> > for the MacPorts install, but I'm not even sure if that'd be desirable for<br>
> > pure Qt5 applications installed through MacPorts ...<br>
><br>
> I don't understand the distinction here.<br>
<br>
</span>There may not be a distinction if indeed the things being looked up depend on the application (and/or KF5) and not on Qt.<br>
<span class=""><br>
> Ian wrote:<br>
> > Perhaps there could be some way for an XDG-based program, from KDE or<br>
> > otherwise, to tell QStandardPaths to setXDGModeEnabled(bool xdgMode).<br>
<br>
> Well, my initial suggestion was to add support for XDG_* env vars to QSP, we<br>
> could do that *without* a default value of /opt/local (unlike my current<br>
> patch), so that nothing happens unless these vars are set. It would do exactly<br>
> that - not affect non-MacPorts apps. This would indeed be "less intrusive".<br>
<br>
</span>Only if you can set those variables only for the applications that require them!<br>
<span class=""><br>
> But you guys said bad things about environment variables so I was trying to<br>
> look for other ideas :-)<br>
<br>
</span>Not bad, but rather sad ;)<br>
<span class="HOEnZb"><font color="#888888"><br>
R.<br>
</font></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><br>
</div></div></blockquote></div><br></div>