El Dimarts, 22 de setembre de 2015, a les 12:52:46, René J.V. Bertin va
escriure:
> Hello,
>
> I'm working on a Mac OS X specific patch that would require adding a small
> object (probably a .o file) to the link list for *all* targets that use
> KF5. This object contains some logic that flips the behaviour of a central
> Qt class which is likely to be used by (almost) all code that depends on
> (or is part of) KF5 : QStandardPaths.
>
> The question : what is the best way to achieve this? Presuming that KF5 uses
> CMake exclusively for its build system, is there a place (macro, default
> list, whatever) where such an object can be added in some kind of
> conditional way (the ECM, for instance)? Or how else would I best proceed?
>
> The context (longish):
> On Mac OS X, QStandardPaths (QSP) returns locations that conform to
> Apple-imposed guidelines that are compatible with App Store sandboxing and
> admission rules.
Shouldn't KF5 work with those sandboxing? I'd expect that KF5 goal is that you
can use it in applications that end up in the App Store.
Cheers,
Albert
> In a nutshell (undoubtedly oversimplified), there are
> little to no shared locations with a direct common parent directory and
> applications are not supposed to be able to access configuration files or
> data also used by other applications. We have attempted to introduce
> changes to Qt, with help from David Faure, but this has been rejected due
> to lack of cohesion and knowing what we really need on our part. In a
> subsequent bug we did obtain recognition of specific needs though:
>
> Distribution systems like MacPorts (a main "source" of KDE4 installs on OS
> X) provide the equivalent of Linux's shared system Qt. They do however not
> only provide FOSS software from Freedesktop contexts, but also provide
> ports/packages/recipes/... for pure Qt open source software. The latter
> must be able to build and function with the distribution's Qt as it would
> with a generic Qt install, and thus get QSP locations that follow Apple's
> guidelines. The former however should be able to get QSP locations that
> follow Freedesktop/XDG guidelines. This should at least help us make KF5
> function (which it doesn't, currently) but should also allow interaction
> with non-KDE Freedesktop ports (GTk/Gnome apps; think something as basic as
> sharing icon themes).
>
> With KDE4 it was easy to implement OS X specific adaptations in KDELibs,
> which made to changes visible to all (well-behaved) KDE applications, and
> not to pure Qt apps. With the migration of so much KDE functionality to Qt
> this is no longer an option.
>
> For QSP, I have thus implemented and tested a patch that allows to switch
> behaviour from returning the (default) Apple-style locations to returning
> XDG-ish locations (${prefix}/share, ${prefix}/etc/xdg, etc.). To increase
> chances of future acceptance into Qt this switch can only be toggled once,
> and in my intended implementation this is done in the ctor of a specific
> class of which a global, static instance is created in the aforementioned
> link-time object.
>
> This has a number of advantages:
> 1) the switch is effective before main() is called (thx Ian Wadham for
> suggesting this) 2) no existing KF5 code has to be changed (=> better
> readability, less maintenance issues) 3) (to be confirmed:) adding the
> object can be constrained to the KF5 build system without modification of
> the qmake or cmake build systems of pure Qt applications. This should make
> the change more acceptable for inclusion into Qt. 4) the addition of the
> link-time module could be made optional once it is clear that KF5 can also
> be made to function with Apple-style QSP locations. (I strongly feel that
> question should be addressed only when KF5 functions satisfactorily with
> "normal" QSP locations.
>
> The question is of course whether there is a chunk of CMake code (CMake
> file) that is executed or loaded by all projects that depend on KF5. I'm
> new to this aspect of development (taking it up because no one else seems
> to be motivated to do so) and have been contenting myself with KDE4 until
> now. From what I've seen, one possible candidate for such common CMake code
> could be the ECM, but are they used by a sufficiently large majority of
> KF5(based) projects?
>
> Thanks for reading all this!
> René
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
