On Thursday September 24 2015 22:56:37 David Faure wrote: > Maybe this needs to be per-method-call then.... : > * if libA installs stuff into XDG paths, then it would find it using > QSP::locate(type, filename, XDG) > * the alternative would be QSP::locate(type, filename, Native), which would > be the default. > This seems more correct to me after all, no? Porting the KDE code would be > just running > one perl script, don't worry about that part.
I've whipped up an alternative patch that is a more or less rough implementation of this idea combined with my thoughts about it described earlier : cf. https://github.com/RJVB/macstrop/blob/master/aqua/qt5-kde-devel/files/patch-QSP-multiple-conventions.diff There's a problem with that approach, though: Qt itself uses QSP; at least QLoggingRegistry::init() (qloggingregistry.cpp:279 for Qt 5.5.0) uses QSP::standardLocations(GenericConfigLocation) to determine where to store/obtain the logging defaults (QtProject/qtlogging.ini) . Using a per-method-call parameter with a default set when Qt is built means libraries calling QSP cannot be toggled after they've been built. For the particular file I happened upon this may be harmless, but I must admit I don't really like the idea. It's bound to lead to conflicts at some point (with full application of Murphy's law, evidently). Of course we could combine the 2 principles to come up with a default convention that means "return the last used convention", but that would mean applications could end up using different conventions during a single run. So that's not an option either. The more I think about it, the more I like the idea of a dedicated standalone framework that sets a (build-time defined) default convention, but can also be used to toggle the convention. That doesn't even have to go against what I said earlier about not targeting only KF5 applications, what with KF5 frameworks intended to be of general use :) I reckon there is already a mechanism in place (in Qt or in KF5) to determine at runtime whether a class method is available (or some kind of weak linking), so that the framework will work with patched and unpatched Qt versions? R. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
