[KDE/Mac] QSP ... again
faure at kde.org
Mon Mar 9 18:05:38 UTC 2015
On Monday 09 March 2015 13:26:52 René J.V. Bertin wrote:
> Following up on
> 79> :
> - is there such a thing as a lowest common denominator component in KF5 that
> all applications link to obligatory (and that is not Qt5Core?)
There isn't, on purpose.
We killed KApplication for a reason ;-)
People should be able to use a KF5 library just like they use any other Qt-
based library, i.e. for a specific purpose only, and without this changing the
rest of the application dramatically (e.g. requiring a global object like a
KApplication or a KComponentData, or initializing too many things under the
hood, or ... changing how QStandardPaths works in the whole application).
So a runtime-switchable mode for QSP sounds like a terrible idea to me.
It makes apps break libs, since toggling this on/off in an app, will make a
lib unable to find the files that it installed. This breaks both ways:
1) app assumes Linux mode, non-kde lib assumes native mode (and installs its
files accordingly), boom.
2) KF5 assumes Linux mode, app sets native mode, boom.
This is actually an argument for making this per call.... i.e. instead of
GenericDataLocation, a new location would be GenericXdgDataLocation, because
the code that makes the call knows that it installed the stuff into an xdg
location. This might look ugly to the Qt people though, I don't know.
If the situation is simply "macports is a self-contained world on a mac os x
environment" then it seems to me that "on macports, QSP should use macports
paths (i.e. mostly xdg-like, but with /opt/local as default). This might mean
patching Qt (upstream or not). But I don't know if this is actually the
reality, I'm having a hard time having a full picture of how things should
work on Mac.
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
More information about the kde-mac