[KDE/Mac] QSP patch back to gerrit?

[René J.V. Bertin]

Taking this to the list. Apologies to Jeremy & Marko who will receive my reply twice.

R.

On Saturday March 14 2015 14:04:20 Jeremy Whiting wrote:

>I haven't checked the patch itself, sorry. I agree with Thiago wondering
>why we can't just add a non static method to QStandardPaths itself to set
>the one flag at runtime though.

A non-static method in a class that cannot be instantiated? And who's going to call it?

As far as I'm concerned, introducing a solution that requires patching each and every bit of code that is supposed to run with the flag set is not an option. We will keep running into issues that after investigation result from having forgotten to set the flag, or worse, because some KF5 developer couldn't be bother to keep those few lines.

>I don't mind being the messenger to push the patch to gerrit. It's really
>not that tricky, just git push origin HEAD:refs/for/dev once origin is the
>gerrit url in your git clone. If it complains about a missing Commit-Id:

Exactly what I thought, it would require maintaining a dedicated git clone for each patch, possibly even for each iteration of the patch.
If you don't mind doing that, great :)

> For the real world, install Foo application/KDE library etc. using the native
>paths from OS X itself seems like a good solution to me. Why do we need to
>not use the system paths when on that system?

Two things. In MacPorts (and probably Fink and company) the system paths for software built on FreeDesktop schemes is not {,~}/Library/Whatever Apple Concocted. Using Apple's schemes may not be impossible despite the examples David Faure gave a while back, but it hasn't been tested. It may work, there may be a use case for it (standalone KF5 applications for those who don't want to depend on MacPorts or company). That's a use case I myself am not interested in, but above all, there will undoubtedly be enough other things on our plates (*) even when we try to stick as closely as possible to the way things work on Linux to factor out as much change as possible.
The whole point of my patch is that it provides a way to select the one QSP policy or the other *without* changing any source code. So once KF5 builds and works in an XDG-like policy, switching to the native policy will be the least difficult step for those who want to work on that.

*) If Kubuntu 15.04's current beta has any reference value there will be plenty of (little?) things *I* will want to correct (or revert) before KF5 becomes acceptable to me.

>and all the others wont that get us working well without any modifications
>to Qt at all ?

We don't know currently if it is possible to come up with such a change in a way that would be sufficiently in line with the official Apple Dogmata for the fanboys out there (O:-)) and that doesn't break on the inevitable space(s) in the path(s). Investigating that will be much easier starting with a working KF5 ensemble.
I have nothing against holding off on submitting the QSP patch for upstream incorporation until this has been figured out, so that the patch could be modified where necessary. But I think that a QSP patch like I'm working on will still be necessary for MacPorts (and company), so there will remain reasons to push for its incorporation upstream.

R.