On Saturday February 28 2015 22:00:07 Ian Wadham wrote:
Hi Ian,
> Esprit d'escalier. We could change GenericDataDir in QStandardPaths to be:
>
> "~/Library/Application Support/Qt5", "/Library/Application Support/Qt5"
>
> That would work for ALL applications that use Qt5 and QSP, regardless of
> origin,
> and would be a more "correct" usage of Apple OS X by the Qt 5 libraries.
And then you'd have to duplicate or migrate everything by the time Qt 6 comes
out ...
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).
The other issue is: how is the build system going to decide in which of the 2
locations above to install stuff?
Has KF5 done away with a ~/.kde/share equivalent that (partly) overrides
things in ${prefix}/share?
> > Crowding out isn't the biggest issue, BTW & IMHO, it's the risk that we end
> > up overwriting or
> > otherwise interfering with stuff that's not ours but happens to be "in the
> > way".
>
> I was thinking the same. I come from an environment where everything had to
> be "uniquified":
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.
R.
