QSP patch/activator (Review Request 126125: [OS X] make KDE's trash use the OS X trash)
René J.V. Bertin
rjvbertin at gmail.com
Sat Nov 28 19:25:49 UTC 2015
On Saturday November 28 2015 15:29:00 David Faure wrote:
>I still have to see proof that a "pure Qt application" installed with MacPorts
>really cares about where QSP points to - apart from the obvious migration issue
>if this ever changes.
The question is not whether individual applications care. The principle is that applications installed through MacPorts (or Fink or whatever) should be able to behave the same way as versions of the same application installed any other way. Take Qt Creator. You can install it through MacPorts, but you can also installed it via Qt's own installers. If you've been using a version from Qt and migrate to the one from MacPorts (or Fink or whatever) or vice-versa, they should use the same configuration, "Application Support" and other directories. Users should be able to launch the one or the other, and find their history, sessions, whatever.
In other words, applications that are designed to function in a standalone fashion and don't need to interact with other, non-Qt5-based XDG-compliant applications should be able to use the native QSP locations (and in fact should do just that).
>Otherwise, the next best idea is to get ECM to add your activator to all link lines
>automatically, e.g. by adding it to CMAKE_EXE_LINKER_FLAGS or whatever.
>This for sure beats editing every link line, or trying to guess which frameworks
>are going to be "used by everyone".
I agree. Full heartedly even. But when I put out a query for suggestion how to accomplish this on k-f-d the only feedback I got could be summarised as "not interested in such a use case".
But how certain is it that all candidates that should use the activator indeed use the ECM?
R.
More information about the Kde-frameworks-devel
mailing list