[KDE/Mac] building kio on Mac

[Jeremy Whiting]

On Sat, Jun 6, 2015 at 3:20 PM, René J.V. <rjvbertin at gmail.com> wrote:
> On Saturday June 06 2015 12:15:43 Allen Winter wrote:
>
>> Too bad  Qt didn't want the upstream fix.
>
> The door hasn't been closed completely, we've basically been sent back to the drawing board and I think I did manage to convince at least some Qt devs that there are special requirements for distribution systems like MacPorts and Fink.
> Those also have the (likely) requirement that shared, freedesktop-style resources like .desktop files and icons should be available to non-KDE applications too without having to duplicate everything.
>
> In the end I came up with a patch that allows to select one of the 2 QSP modes, defaulting to Qt's standard behaviour, and a switch that is basically applied when building the "client" (a global instance of a class with a ctor that flips the switch in the QSP class). This can be done simply by adding a module to the list of libraries to be linked to, which means that the selection is made even before main() is called (and in my current implementation, the selection can only be made once).
> What remains to be done is figure out an acceptable way to inject such a module, which I hope shouldn't be too hard.
>
> I think that once we have a draft that works to satisfaction we can attempt another Qt code review, possibly marking it a WIP which tends to change attitudes some people have to proposed changes ;)
> One of the reasons Jeremy's patch was rejected in the end is that we didn't have sufficient consensus on our end (and I'm probably not the one with the least amount of badly phrased contributions to the review in question).
>
>> And I suppose we aren't interesting in resurrecting KStandardDirs either.
>> rock vs. hard-place. neither side will yield
>
> There is of course something to say for the position that KDE apps should be able to function with whatever QSP provides, supposing of course that that's possible. It's probably not a coincidence that QStandardPaths replaces KStandardDirs on Linux, but the opposite might well be true on (most) other platforms. That would indeed be somewhere between a rock and a hard place, with a custom Qt as the only (?) way out.
> But even if KDE *can* work with stock QSP on OS X, that doesn't mean it can (as in shall) not work any other way there:

Yeah, good point.
>
>> So it seems like we can't specify defaults that will satisfy even most
>> people, let alone everyone.
>
> Welcome to the real world ...
>
>> The best I can see us doing is implementing
>> some sort of "profile" system in KDEInstallDirs that would switch the
>> defaults wholesale by specifying a single argument. I don't know whether
>> that would be worth it or not - depends how easy it is to implement and
>> maintain, I guess.
>
> I thought there was no single common startup/initialisation path that all KF5 applications follow, provided by a basic module (that is not Qt itself)? I think that may prove to be an oversight if KF5 is to be cross-platform, but that's a different topic.
> If KDEInstallDirs can toggle QSP between modes, possibly doing that before calling any of QSP's *Path functions, that would probably be an easier solution that the additional link-time module I had in mind. How would you communicate that single argument? A switch applied when building KDEInstallDirs itself, or a setting in a global config file (kdeglobals or equivalent)?

I don't think that will work, except as a way to set the flag needed
for the non standard paths use. KDEInstallDirs is just a cmake macro
used at build time. not a runtime thing that all KF5 based
applications use.

BR,
Jeremy

>
> R.
>
> _______________________________________________
> kde-mac at kde.org
> List Information: https://mail.kde.org/mailman/listinfo/kde-mac
> KDE/Mac Information: http://community.kde.org/Mac