<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 28, 2015 at 4:51 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">On Saturday February 28 2015 22:00:07 Ian Wadham wrote:<br>
<br>
Hi Ian,<br>
<span class=""><br>
> Esprit d'escalier.  We could change GenericDataDir in QStandardPaths to be:<br>
><br>
>      "~/Library/Application Support/Qt5", "/Library/Application Support/Qt5"<br>
><br>
> That would work for ALL applications that use Qt5 and QSP, regardless of origin,<br>
> and would be a more "correct" usage of Apple OS X by the Qt 5 libraries.<br>
<br>
</span>And then you'd have to duplicate or migrate everything by the time Qt 6 comes out ...<br>
I'd hope that Qt version-specific stuff is already installed by Qt itself in an appropriate place that's under configure control (${prefix}/share/qt5 with my qt5-mac-devel port).<br></blockquote><div><br></div><div>Then data will all be under ~/Library/Application Support/Qt5/appname ? that's a bit cleaner, but why would Qt/KDE applications need to use a namespace like that when apple's own applications don't? Here I see ~/Library/Application Support/kf5 for all frameworks as it is, I don't think any frameworks or applications are using GenericDataLocation directly, they all use a subfolder of it, otherwise we would see application data files in /usr/share on linux which isn't recommended either.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The other issue is: how is the build system going to decide in which of the 2 locations above to install stuff?<br>
Has  KF5 done away with a ~/.kde/share equivalent that (partly) overrides things in ${prefix}/share?<br></blockquote><div><br></div><div>kf5 based libraries and applications on linux are using ~/.local/applicationname mostly now. which overrides ${prefix}/share yes.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> > Crowding out isn't the biggest issue, BTW & IMHO, it's the risk that we end up overwriting or<br>
> > otherwise interfering with stuff that's not ours but happens to be "in the way".<br>
><br>
> I was thinking the same.  I come from an environment where everything had to be "uniquified":<br>
<br>
</span>And as I said earlier, there's also the question of all the non-KDE/KF5 applications that use freedesktop/xdg-style data paths that are conceived to be shared with KDE/KF5 (icons, themes, styles, the shared-mime database, .desktop/.service/dbus files, etc). There are loads of those in MacPorts (and Fink, and ...) and I think they're more widely used than KDE applications, so we have to factor in their existence. As well as MacPorts' policy to install everything in its own prefix (as well as the policies of the other major packaging efforts). There are just too many dependencies not to use MacPorts or similar, and OS X is different enough from Linux to make rolling our own standalone, "do-as-the-romans-do" distribution scheme a daunting task that I won't have anything to do with.<br></blockquote><div><br></div><div>Which of those are using Qt or QStandardPaths though? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
R.<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></div></div></blockquote></div><br></div></div>