[Alexpux/MINGW-packages] qt5: add new functions better fit MSYS2 needs (#1640)

[René J.V. Bertin]

On Friday August 19 2016 12:10:54 David Faure wrote:

> The discussions at the last Randa meeting, with the people involved in porting 
> KDE applications (e.g. kate/kdevelop/etc.) to OSX and Windows, convinced me 
> that a XDG mode for QSP on OSX and Windows is unnecessary.

I am pretty much convinced that none of those people were involved with porting KDE applications to projects like MacPorts, Fink etc. Or MSYS/Cygwin. On the contrary, I have every reason to believe that most of those people have a problem with MacPorts and the like.
Those efforts do need an alternative mode, there's just no way around that if KDE apps are to be installed and function as much as possible as they are on their native/traditional platform. And frankly, I don't believe it'll be feasible to port complex applications like KDE PIM to OS X using the all-encompassingly standalone app bundle approach.

I knew it was a monumental error not to be at Randa, but it just wasn't possible for me. How many of the porters present are actual long-term OS X users who really know the platform beyond what Apple like it to be?

> In any case, QExtStandardPaths is a hack, a proper Qt patch would add paths to 
> QSP, rather than creating an "Ext" class.

I resent calling the Ext class a hack. It is only there to make the patch as transparent as possible, and to limit the maintenance required for existing code. The current approach is also designed to avoid issues where host app and plugin interfere with their respective expectations, a possibility you evoked yourself (and which in practice happens only in very specific conditions).
How is one going to add paths to QSP in such a way that it doesn't apply globally - provide them as an argument to each and every QSP call? If so, why still bother having a QSP class?
I agree that it would be better if the alternative writable and additional readable paths can be specified at runtime rather than being hardcoded, but that still doesn't remove the need for a mode switch if a single Qt install is supposed to cater applications that require native QSP and ones that don't.

R.