[KDE/Mac] Fwd: Qtbase patch for configurable standard paths

[René J.V. Bertin]

On Tuesday January 19 2016 10:24:34 David Faure wrote:

>> The end result is that QSP::writableLocation is specified through qt.conf.
>
>Once more, writableLocation isn't the interesting part (and I don't recommend changing it). What's interesting
>is the lookup of installed files, which is standardLocations()

I know, and we don't agree on that (and still think that's a minor detail, one I should be able to address in a much simpler patch once we find a good solution for standardLocations()).

I do still have the question exactly what writableLocation() is used for; maybe only to determine the location of new configuration (and other resource) files, when none are found in the places specified by standardLocations()? That would fit with what I observed.
The QSP documentation that comes with Qt doesn't really say how the information returned is to be used (or I need new reading glasses).

Anyway, I was just describing how I read the patch.

>AFAIU it allows to add search paths for standardLocations() in qt.conf.

Do you see any modification of standardLocations()? There's none in the patch you included.

>I'll let you read the documentation for qt.conf, since I don't know all the search paths for it. Or you can ask Patrick.

Hmmok. I know I should, but with the experience that such documentation mostly comes from (and is only as good as) the inline comments I thought it wouldn't hurt to ask first ;)

>> Bonus question: what about your own Scribus example?
>
>No breakage when only adding *additional* search paths.

As I said in the other thread, that's also the main component of what my current patch does. It doesn't introduce breakage if all expected files already exist in a location returned by standardLocations(). From what I'm beginning to understand, the breakage in the Scribus example is thus of the assumption that a "pure Qt" application installed through MacPorts would use the same locations for its user-modifiable resources as the same version installed through some other means. And this assumption would be violated only for users who never used Scribus before it linked to a KF5 framework.

It is breakage of course, but the only thing I can come up with that wouldn't work as expected is the configuration of user settings of features provided by a KF5 framework (shortcuts, KTextEditor settings) when the user used Scribus before using a "real KF5" application like Kate. And even in that case the unexpected aspect is the location of the settings file.

R.