[KDE/Mac] QSP patch back to gerrit?

[Jeremy Whiting]

Rene,

On Sun, Mar 15, 2015 at 3:58 AM, René J.V. <rjvbertin at gmail.com> wrote:

> 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 :)
>

How did you come to that conclusion? I have one clone of QtSpeech here for
example with a few different patches in different branches that I push to
gerrit after reacting to feedback. No need for a separate clone per
patch...

>
> > 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.
>

I see, ok.

>
> R.
> _______________________________________________
> kde-mac at kde.org
> List Information: https://mail.kde.org/mailman/listinfo/kde-mac
> KDE/Mac Information: http://community.kde.org/Mac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20150315/b4de3534/attachment.html>