Hi, I just remembered that some time ago I wrote a small library that allows me to use binaries compiled against my own patched qt5-kde with an "official" Qt build: it provides the additional symbols that are in qt5-kde but not standard Qt through code injection (DYLD_INSERT_LIBRARIES). That isn't really a kosher thing to do (and actively discouraged on newer Mac OS versions) but it brings me to this:
Could we design a kind of Qt plugin that provides an alternative QSP, a bit like how the plasma-integration plugin provides the KDE file dialog? In first testing/internal approach that could use a similar trick as the one I'm using with my QExtStandardPaths (a macro definition given in CPPFLAGS) and if that replaces every QStandardPaths::foo() call with (say) a KStandardLocations::foo() call we could just as well use an additional link library rather than a plugin. But ultimately I'm thinking of a plugin that provides alternative methods in QStandardPaths which user code could decide to use (or not) and which would by default just proxy their standard counterparts. Such a system would provide the same kind of flexibility as a solution where qt.conf is used, but in a way that is probably easier to deploy on other platforms, less easy to tinker with by mere mortal endusers and that probably requires touching less files. It might thus be easier to upstream. A long time ago David Faure pointed out to me that an application-wide solution that toggles QSP behaviour throughout an application is best avoided as it has the potential of doing that toggle at any time when an application is running. Instead, every dynamically loadable component should have its own, fixed QSP behaviour. (This is of course relevant mostly if not only for "linuxy" centralised installs.)
